BR112012006374B1

BR112012006374B1 - Sistema de streaming de requisição em bloco aperfeiçoado utilizando sinalização ou criação de blocos

Info

Publication number: BR112012006374B1
Application number: BR112012006374-0A
Authority: BR
Inventors: Michael G. Luby; Mark Watson; Lorenzo Vicisano; Payam Pakzad; Bin Wang; Ying Chen; Thomas Stockhammer
Original assignee: Qualcomm Incorporated
Priority date: 2009-09-22
Filing date: 2010-09-22
Publication date: 2021-07-20
Also published as: KR20120080208A; ES2734257T3; JP2019205175A; WO2011038013A3; CA2854008C; KR101395193B1; JP2022070940A; CN102577411B; HUE044122T2; KR101562274B1; MY163822A; US20160323342A1; KR101456987B1; RU2553101C2; RU2012116086A; DK2481197T3; JP6685989B2; JP7024125B2; ZA201202935B; CA2854011C

Abstract

sistema de streaming de requisição em bloco aperfeiçoado utilizando sinalização ou criação de blocos. um sistema de requisição em blocos propicia melhorias na experiência do usuário e na eficiência de amplitude de banda de tais sistemas, usando tipicamente um sistema de ingestão que gera dados em uma forma a ser servida por um servidor de arquivos convencional (http, ftp, ou similares), em que o sistema de ingestão recebe conteúdo e o prepara na forma de arquivos ou elementos de dados a serem servidos pelo servidor de arquivos. o sistema poderia incluir c) controle da seqüência, timing e montagem de requisições de blocos, indexação baseada em tempo, dimensionamento de blocos variável, particionamento de blocos ideal, controle de posicionamento de ponto de acesso aleatório, incluindo através de múltiplas versões de apresentação, atualização dinâmica de dados de apresentação e/ou apresentação eficiente de conteúdo ao vivo e deslocamento no tempo.

Description

Referencias Cruzadas a Pedidos Correlacionados

[0001] O presente pedido constitui um pedido de patente não provisório que reivindica a prioridade dos seguintes Pedidos Provisórios, cada um deles em nome de Michael G. Luby, et al., todos intitulados “ENHANCED BLOCK REQUEST STREAMING SYSTEM”:

[0002] Pedido Provisório de Patente U.S. No de Série 61/244 767, depositado em 22 de setembro de 2009;

[0003] Pedido Provisório de Patente U.S. No de Série 61/257 719, depositado em 03 de novembro de 2009;

[0004] Pedido Provisório de Patente U.S. No de Série 61/258 088, depositado em 04 de novembro de 2009;

[0005] Pedido Provisório de Patente U.S. No de Série 61/285 779, depositado em 11 de dezembro de 2009; e

[0006] Pedido Provisório de Patente U.S. No de Série 61/285 779, depositado em 20 de janeiro de 2010.

[0007] O presente pedido também reivindica a prioridade do Pedido Provisório de Patente U.S. No de Série 61/372 399, depositado em 10 de agosto de 2010, em nome de Ying Chen et al., intitulado “HTTP STREAMING EXTENSIONS”.

[0008] Cada pedido provisório acima mencionado é aqui incorporado pela presente referência para todas as finalidades. A presente descrição incorpora também como referência, tal como se fossem anexados em sua totalidade ao presente documento, e para todas as finalidades, os seguintes pedidos/patentes da Requerente:

[0009] Patente U.S. No 6 307 487 de luby (a seguir designada como “Luby I”);

[00010] Patente U.S. No 7 068 729 de Shokrollahi et al. (a seguir designada como “Shokrollahi I”)

[00011] Pedido de Patente U.S. No de Série 11/423 391, depositado em 9 de junho de 2006, intitulado “FORWARD ERROR CORRECTING (FEC) CODING AND STREAMING”, em nome de Luby et al. (a seguir designada como “Luby II”);

[00012] Pedido de Patente U.S. No de Série 12/103 605, depositado em 15 de abril de 2008, intitulado “DYNAMIC STREAM INTERLEAVING AND SUB-STREAM BASED DELIVERY”, em nome de Luby et al. (a seguir designada como “Luby III”);

[00013] Pedido de Patente U.S. No de Série 12/705 502, depositado em 12 de fevereiro de 2010, intitulado “BLOCK PARTITIONING FOR A DATA STREAM”, em nome de Pakzad et al. (a seguir designada como ‘Pakzad”); e

[00014] Pedido de Patente U.S. No de Série 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”, em nome de Luby et al. (a seguir designada como “Luby IV”)

Campo da invenção

[00015] A presente invenção está relacionada a sistemas e métodos para streaming de mídia aperfeiçoados que são adaptáveis às condições de rede e de buffers de modo a otimizar uma apresentação de mídia em stream e permitir um transporte eficiente, concomitante ou distribuído no tempo, de dados de mídia em stream.

Fundamentos da Invenção

[00016] O transporte de mídia em streaming pode se tornar cada vez mais importante a medida em que se torna mais comum o transporte de áudio e vídeo de alta qualidade através de redes baseadas em pacotes, tais como a Internet, redes celulares e wireless, redes de energia, e outros tipos de redes. A qualidade com a qual o streaming de mídia transportado pode ser apresentado pode depender de inúmeros fatores, incluindo a resolução (ou outros atributos) do conteúdo original, a qualidade de codificação do conteúdo original, os recursos dos dispositivos receptores e assim por diante. Para criar uma boa experiência de mídia em streaming, o transporte e o timing do sinal recebido nos receptores pode ser especialmente importante. Um bom transporte pode prover fidelidade da corrente recebida no receptor com relação ao que um emissor envia, enquanto o timing/tempestividade pode representar o quão rapidamente um receptor pode iniciar a reprodução do conteúdo após uma requisição inicial para tal conteúdo.

[00017] Um sistema de transporte de mídia pode ser caracterizado como um sistema possuindo fontes ou origens de mídia, destinos de mídia e canais (no tempo e/ou espaço) separando as fontes e os destinos. Tipicamente, uma fonte ou origem inclui um transmissor com acesso a mídia em uma forma eletronicamente gerenciável, e um receptor com uma capacidade de controlar eletronicamente a recepção dos mídia (ou uma aproximação dos mesmos) e prove- los para um consumidor de mídia (por exemplo, um usuário possuindo um dispositivo de display/apresentação acoplado de alguma forma ao receptor, um elemento ou dispositivo de armazenamento, outro canal e assim por diante).

[00018] Apesar de inúmeras variações serem possíveis, em um exemplo comum, um sistema de transporte de mídia possui um ou mais servidores que possuem acesso ao conteúdo de mídia em forma eletrônica, e um ou mais dispositivos ou sistemas clientes efetuam requisições de mídia para os servidores, e os servidores levam os mídia usando um transmissor como parte do servidor, transmitindo para um receptor no cliente de forma que os mídia recebidos possam ser consumidos pelo cliente de alguma forma. Como um exemplo simples, existem um servidor e um cliente para uma dada requisição e resposta, porém tal não necessita ser o caso.

[00019] Tradicionalmente, os sistemas de transporte/distribuição de mídia podem ser caracterizados como um modelo de “download” ou um modelo de “streaming”. O modelo de download poderia ser caracterizado pela independência de timing entre o transporte/entrega dos dados de mídia e a reprodução dos mídia para o usuário ou dispositivo receptor.

[00020] Como exemplo, os mídia são “baixados” ou downloaded com suficiente antecedência do momento em que serão necessários ou serão usados e, quando são usados, uma quantidade suficiente já estará disponível no receptor. O transporte ou entrega no contexto de download é amiúde efetuado pelo uso de um protocolo de transporte de arquivos, tal como o HTTP, FTP, ou FLUTE (File Delivery Over Unidirectional Transport - distribuição de arquivos através de transporte unidirecional), e a taxa/velocidade de distribuição pode ser determinada por um protocolo de controle de congestionamento e/ou fluxo subjacente, tal como o TCP/IP. A operação do protocolo de controle de congestionamento ou fluxo pode ser independente da reprodução dos mídia para o usuário ou dispositivo de destino, o qual pode ocorrer concomitantemente com o download, ou em alguma outra ocasião.

[00021] O modo de “streaming” pode ser caracterizado por um acoplamento justo entre o timing da distribuição dos dados de mídia e a reprodução dos mídia para o usuário ou dispositivo receptor. A distribuição ou transporte em tal contexto é amiúde efetuado através do uso de um protocolo de streaming, tal como o RTSP (protocolo de streaming em tempo real) para controle e o RTP (protocolo de transporte em tempo real) para os dados de mídia. A taxa de transporte pode ser determinada por um servidor de streaming, amiúde em compasso com a taxa/velocidade de reprodução dos dados.

[00022] Algumas desvantagens do modelo “download” podem incluir o fato de que, devido à independência de timing da distribuição/transporte e reprodução, os dados de mídia podem não estar disponíveis quando forem necessários para a reprodução (por exemplo, devido ao fato de que a amplitude de banda disponível é menor do que a taxa de dados de mídia), levando ou à momentânea interrupção da reprodução (“estol”/“stalling”), o que resulta em uma experiência desagradável para o usuário, ou à necessidade de download dos dados de mídia com grande antecedência à reprodução (por exemplo, devido ao fato de que a amplitude de banda disponível ser maior do que a taxa de dados de mídia), consumindo recursos de armazenamento no dispositivo receptor, os quais podem ser poucos, e consumo de recursos valiosos da rede para o transporte, os quais serão desperdiçados, caso o conteúdo não seja, eventualmente, reproduzido ou utilizado.

[00023] Uma vantagem do modelo de “download” é a de que a tecnologia necessária para efetuar tais downloads, por exemplo em HTTP, já estão bem estabelecidos, são amplamente empregados e podem ser aplicados em uma ampla gama de aplicações. Os servidores de download e as soluções para o amplo escalonamento de tais downloads de arquivos (por exemplo, HTTP Web Servers e redes de transporte/distribuição de conteúdo) podem estar facilmente disponíveis, tornando simples e barata a implementação de serviços com base em tal tecnologia.

[00024] Algumas desvantagens do modelo de “streaming” incluem o fato de que, de um modo geral, a taxa de transporte dos dados de mídia não está adaptada à amplitude de banda disponível na conexão servidor - cliente, e que são necessários servidores de streaming especializados ou uma estrutura de rede mais complexa que proporcione garantias de amplitude de banda e retardo. Apesar de existirem sistemas de streaming que dão suporte à variação da taxa de dados de distribuição de acordo com a amplitude de banda disponível (por exemplo, AFAS - Adobe Flash Adaptive Streaming), eles não são, de um modo geral, tão eficientes como protocolos de controle de fluxo de transporte de download, tais como o TCP, na utilização de toda a amplitude de banda disponível.

[00025] Recentemente, foram desenvolvidos e implementados novos sistemas de transporte/distribuição de mídia baseados em uma combinação dos modelos de “streaming” e “download’. Como exemplo, um de tais modelos é aqui designado como um modelo de “streaming por requisição de blocos”, em que um cliente de mídia requisita blocos de dados de mídia a partir da infraestrutura servidora usando um protocolo de download, tal como o HTTP. Uma consideração em tais sistemas pode ser a capacidade de iniciar a reprodução de uma corrente/stream, por exemplo a decodificação e apresentação de correntes de áudio e vídeo utilizando um computador pessoal e apresentação do vídeo em uma tela/monitor de computador e reprodução do áudio através de alto-falantes embutidos, ou, como outro exemplo, a decodificação e apresentação das correntes de áudio e vídeo recebidas usando-se um “set top box” e apresentação do vídeo em um dispositivo de display de televisão e reprodução do áudio através de um sistema estéreo.

[00026] Outras considerações, tais como a capacidade de decodificar os blocos fonte com rapidez suficiente para acompanhar a taxa de streaming da fonte, para minimizar a latência de decodificação e reduzir o uso dos recursos disponíveis da CPU, constituem preocupações. Outra consideração reside em prover uma solução de distribuição em streaming estável e escalonável que permita a falha dos componentes do sistema sem afetar adversamente a qualidade das correntes entregues aos receptores. Outros problemas poderiam ocorrer com base em informações sobre uma apresentação que se modificam rapidamente a medida em que ela está sendo distribuída. Dessa forma, são desejáveis melhores e equipamentos.

Breve Resumo da Invenção

[00027] Um sistema de streaming por requisição de blocos proporciona melhorias na experiência do usuário e eficiência de amplitude de banda de tais sistemas, usando tipicamente um sistema de ingestão que gera dados em uma forma a ser servida por um servidor de arquivos convencional (HTTP, FTP, ou similar), em que o sistema de ingestão absorve conteúdo e o prepara na forma de arquivos ou elementos de dados a serem servidos pelo servidor de arquivos, o qual pode ou não incluir um cache. Um dispositivo cliente pode estar adaptado para fazer proveito do processo de ingestão, bem como incluir melhorias que propiciam uma melhor apresentação independentemente do processo de ingestão.

[00028] Tais modalidades incluem novos aperfeiçoamentos para métodos usados em um cliente de streaming por requisição de blocos e em um sistema de ingestão de requisição de blocos para determinar a seqüência, timing e montagem de requisições de blocos, incluindo o provimento de indexação baseada em tempo. Em algumas modalidades, são providos novos aperfeiçoamentos para métodos para montagem de blocos e arquivos, incluindo dimensionamento de blocos variável e particionamento ideal de blocos. Em algumas modalidades, são providos novos aperfeiçoamentos para métodos de posicionamento de ponto de acesso aleatório, inclusive o posicionamento de ponto de acesso aleatório através de múltiplas versões de apresentação. Em algumas modalidades, são providos novos aperfeiçoamentos para métodos para atualização dinâmica de dados de apresentação, incluindo sinalização dentro de metadados. Em algumas modalidades, são providos novos aperfeiçoamentos para métodos de apresentação eficiente de conteúdo ao vivo e deslocamento/shift de tempo.

[00029] A descrição detalhada que se segue, em conjunto com os desenhos anexos, propiciarão uma melhor compreensão da natureza e vantagens da presente invenção.

Breve Descrição dos Desenhos

[00030] A Figura 1 ilustra elementos de um sistema de streaming por requisição de blocos de acordo com modalidades da presente invenção.

[00031] A Figura 2 ilustra o sistema de streaming por requisição de blocos da Figura 1, apresentando maiores detalhes nos elementos de um sistema cliente que está acoplado a uma infraestrutura servidora de blocos (BSI) para a recepção de dados que são processados por um sistema de ingestão de conteúdo.

[00032] A Figura 3 ilustra uma implementação em hardware/software de um sistema de ingestão.

[00033] A Figura 4 ilustra uma implementação em hardware/software de um sistema cliente.

[00034] A Figura 5 ilustra estruturas possíveis para o armazenamento de conteúdo apresentado na Figura 1.

[00035] A Figura 6 ilustra detalhes de um típico segmento fonte, tal como poderia ser armazenado no armazenamento de conteúdo ilustrado nas Figuras 1 e 5.

[00036] As Figuras 7a e 7b ilustram a indexação simples e hierárquica dentro de arquivos.

[00037] A Figura 8a ilustra o dimensionamento de blocos variável com pontos de busca alinhados em uma pluralidade de versões de uma corrente de mídia.

[00038] A Figura 8b ilustra o dimensionamento de blocos variável com pontos de busca não alinhados em uma pluralidade de versões de uma corrente de mídia.

[00039] A Figura 9a ilustra uma Tabela de Metadados.

[00040] A Figura 9b ilustra a transmissão de blocos e da Tabela de Metadados do servidor para o cliente.

[00041] A Figura 10 ilustra blocos que são independentes de limites RAP.

[00042] A Figura 11 ilustra o timing contínuo e descontínuo através de segmentos.

[00043] A Figura 12 ilustra um aspecto de blocos escalonáveis.

[00044] A Figura 13 ilustra uma representação gráfica da evolução de certas variáveis em um sistema de streaming por requisição de blocos ao longo do tempo.

[00045] A Figura 14 ilustra outra representação gráfica da evolução de certas variáveis em um sistema de streaming por requisição de blocos ao longo do tempo.

[00046] A Figura 15 ilustra uma grade celular de estados como uma função de valores limite.

[00047] A Figura 16 ilustra um fluxograma de um processo que poderia ser efetuado em um receptor que pode requisitar blocos únicos e múltiplos blocos por requisição.

[00048] A Figura 17 ilustra um fluxograma de um processo em pipeline flexível.

[00049] A Figura 18 ilustra um exemplo de um conjunto de candidatas de requisições, suas prioridades e quais conexões em que elas podem ser emitidas, em um dado momento.

[00050] A Figura 19 ilustra um exemplo de um conjunto de candidatas de requisições, suas prioridades e quais conexões em que elas podem ser emitidas, que se modificou de um instante para outro.

[00051] A Figura 20 ilustra um fluxograma de seleção consistente de proxy de servidor de caching com base em um identificador de arquivos.

[00052] A Figura 21 ilustra uma definição de sintaxe para uma linguagem de expressão adequada.

[00053] A Figura 22 ilustra um exemplo de uma função hash adequada.

[00054] A Figura 23 ilustra exemplos de regras de montagem de identificador de arquivo.

[00055] As Figuras 24a a 24e ilustram as flutuações de amplitude de banda de conexões TCP.

[00056] A Figura 25 ilustra múltiplas requisições HTTP para dados de reparo e fonte.

[00057] A Figura 26 ilustra um exemplo de tempo de zapping de canal com e sem FEC.

[00058] A Figura 27 ilustra detalhes de um gerador de segmento de reparo que gera, como parte do sistema de ingestão apresentado na Figura 1, segmentos de reparo a partir de segmentos fonte e parâmetros de controle.

[00059] A Figura 28 ilustra as relações entre blocos fonte e blocos de reparo.

[00060] A Figura 29 ilustra um procedimento para serviços ao vivo em diferentes instantes no cliente.

[00061] Nas figuras, itens similares são referenciados por números semelhantes e sub-índices são providos entre parênteses para indicar múltiplos casos de itens similares ou idênticos. A menos de indicação em contrário, o sub-índice final (por exemplo, “N” ou “M”) não tenciona constituir um limite a qualquer valor específico e o número de casos de um item pode diferir do número de casos de outro item, mesmo quando os mesmos números são ilustrados e o sub-índice é reutilizado.

Descrição Detalhada da Invenção

[00062] Tal como é aqui descrito, uma meta de um sistema de streaming consiste em mover mídia de sua localização de armazenamento (ou do local onde eles estão sendo gerados) para um local em que eles estão sendo consumidos, isto é, apresentados a um usuário ou de outra forma “usados” por uma pessoa ou um consumidor eletrônico. Idealmente, o sistema de streaming pode prover reprodução/playback sem interrupções (ou, de um modo mais geral, “consumo” não interrompido) em uma ponta de recepção e pode iniciar a reprodução de uma corrente/stream, ou de uma coletânea de correntes logo após um usuário ter requisitado a corrente ou correntes. Por razões de eficiência, é também desejável que cada corrente seja sustada uma vez que o usuário indique que a corrente não é mais necessária, tal como quando o usuário está comutando de uma corrente para outra corrente, ou quando ele obedece à apresentação de uma corrente, por exemplo, a corrente de “legendas”. Caso o componente de mídia, tal como o vídeo, continue a ser apresentado, porém uma corrente diferente é selecionada para apresentação de tal componente de mídia, é amiúde preferida a ocupação de uma amplitude de banda limitada com a nova corrente/stream e a sustação da corrente anterior.

[00063] Um sistema de streaming por requisição de blocos de acordo com modalidades aqui descritas propicia vários benefícios. Deve ficar claro que um sistema viável não necessita incluir todos os recursos aqui descritos, dado que alguns aplicativos poderiam propiciar uma experiência adequadamente satisfatória com apenas alguns dos recursos aqui descritos.

Streaming HTTP

[00064] O streaming HTTP constitui um tipo específico de streaming. Com o streaming HTTP, as fontes podem ser servidores de rede e redes de distribuição de conteúdo (CDNs) padrão e podem usar o HTTP padrão. Tal técnica pode envolver a segmentação e o uso de múltiplas correntes/streams, tudo dentro do contexto de requisições HTTP padronizadas. Os mídia, tais como um vídeo, podem ser codificados em múltiplas taxas de bits/bitrates para a formação de diferentes versões ou representações. Os termos “versão” e “representação” são usados como sinônimos no presente documento. Cada versão ou representação pode ser quebrada ou separada em peças/pedaços menores, cada um talvez da ordem de alguns segundos, para a formação de segmentos. Cada segmento pode a seguir ser armazenado em um web server/servidor ou CDN na forma de um arquivo separado.

[00065] Na ponta do cliente, as requisições podem ser então efetuadas, usando-se HTTP, para segmentos individuais que são emendados sem intervalos pelo cliente. O cliente pode se comutar para taxas de dados diferentes com base na amplitude de banda disponível. O cliente pode também requisitar múltiplas representações, cada uma apresentando um diferente componente de mídia, podendo apresentar os mídia em tais representações de forma unida e síncrona. Os acionadores ou “gatilhos” para a comutação podem, por exemplo, incluir medições da rede e da ocupação de buffers. Ao operar em regime/steady state, o cliente pode moderar as requisições para o servidor de modo a manter uma ocupação de buffer meta.

[00066] As vantagens do streaming HTTP podem incluir adaptação da taxa de bits, inicialização e busca rápidas e um mínimo de transporte/distribuição desnecessária. Tais vantagens advêm do controle da distribuição de modo a ocorrer apenas um curto tempo antes da reprodução, fazendo o uso máximo da amplitude de banda disponível (através de mídia de taxa de bits variável) e otimização da segmentação de correntes e procedimentos de cliente inteligentes.

[00067] Uma descrição de apresentação de mídia pode ser provida para um cliente de streaming HTTP de tal forma que o cliente possa usar uma coletânea de arquivos (por exemplo, em formatos especificados pela norma 3GPP, aqui denominados como segmentos 3GPP) para prover um serviço de streaming para o usuário. Uma descrição de apresentação de mídia, e possivelmente atualizações de tal descrição de apresentação de mídia, descreve uma apresentação de mídia que constitui uma coleção estruturada de segmentos, cada um contendo componentes de mídia tais que o cliente possa apresentar os mídia incluídos de uma maneira sincronizada e possa prover recursos avançados, tais como busca/pesquisa, comutação de bitrates e apresentação conjunta de componentes de mídia em diferentes representações. O cliente pode usar as informações de descrição de apresentação de mídia de diferentes formas para o provimento do serviço. Em particular, a partir da descrição de apresentação de mídia, o cliente pode determinar quais segmentos na coleção podem ser acessados de forma a que os dados sejam úteis para a capacidade do cliente e o usuário dentro do serviço de streaming.

[00068] Em algumas modalidades, a descrição de apresentação de mídia pode ser estática, apesar de segmentos poderem ser criados dinamicamente. A descrição de apresentação de mídia pode ser tão compacta quanto possível de modo a minimizar o tempo de acesso e download para o serviço. Outras conectividades dedicadas do servidor podem ser minimizadas, por exemplo uma sincronização de timing regular ou freqüente entre o cliente e o servidor.

[00069] A apresentação de mídia pode ser montada de forma a permitir o acesso por terminais com diferentes capacidades, tal como o acesso a diferentes tipos de redes de acesso, diferentes condições corrente da rede, tamanhos de display, bitrates de acesso e suporte a CODEC. O cliente pode a seguir extrair as informações apropriadas de modo a prover o serviço de streaming ao usuário.

[00070] A descrição de apresentação de mídia pode também permitir flexibilidade de implementação e compactação de acordo com as exigências.

[00071] Em um caso mais simples, cada representação alternativa pode ser armazenada em um único arquivo 3GPP, isto é, um arquivo conforme definido em 3GPP TS 26.244, ou qualquer outro arquivo que esteja de acordo com o formato de arquivos de mídia de base ISO tal como definido em ISO/IEC 14496-12, ou especificações derivadas (tais como o formato de arquivo 3GPP descrito na 3GPP Technical Specification 26,244). No restante do presente documento, quando for feita referência a um arquivo 3GPP deve ficar claro que a ISO/IEC 14496-12 e especificações derivadas podem mapear todos os recursos/características para o formato de arquivo mais geral de base ISO tal como definido em ISO/IEC 14496-12 ou quaisquer especificações derivadas. O cliente pode a seguir requisitar uma parte inicial do arquivo para “aprender” os metadados de mídia (os quais ficam tipicamente armazenados no movie header box/partição de cabeçalho do filme, também designado como o “moov” box) juntamente com os tempos e offsets de bytes de fragmentos do filme. O cliente pode a seguir emitir requisições de obter HTTP parcial para obtenção de fragmentos de filme conforme requerido.

[00072] Em algumas modalidades, pode ser desejável dividir cada representação entre vários segmentos, em que os segmentos. Caso o formato dos segmentos seja baseado no formato de arquivo 3GPP, os segmentos contêm “fatias” de tempo que não se sobrepõem dos fragmentos do filme denominados “emenda temporal” ou “time-wise splitting”. Cada um de tais segmentos pode conter múltiplos fragmentos de filme, e cada um pode ser um arquivo 3GPP válido por si só. Em outra modalidade, a representação é dividida em um segmento inicial contendo os metadados (tipicamente a caixa moov do header/cabeçalho do filme) e um conjunto de segmentos de mídia, cada um deles contendo dados de mídia e a concatenação do segmento inicial e qualquer segmento de mídia forma um arquivo 3GPP válido, bem como a concatenação do segmento inicial e todos os segmentos de mídia de uma representação formam um arquivo 3GPP válido. A totalidade da apresentação pode ser formada através da reprodução de cada segmento em ordem, mapeando as marcas de tempo/timestamps locais dentro do arquivo para o tempo de apresentação global de acordo com o instante inicial de cada representação.

[00073] Deve ser notado que por toda a presente descrição as referências a um “segmento” devem ser entendidas como incluindo quaisquer objetos de dados que sejam total ou parcialmente montados ou lidos a partir de um meio de armazenamento, ou de outra forma obtidos como resultado de uma requisição de protocolo de download de arquivo, incluindo, por exemplo, uma requisição HTTP. Como exemplo, no caso do HTTP, os objetos de dados podem estar armazenados em arquivos reais residentes em um disco ou outro meio de armazenamento conectado a, ou fazendo parte de, um servidor HTTP, ou os objetos de dados podem ser montados por meio de um script CGI, ou outro programa dinamicamente executado, o qual é executado em resposta à requisição HTTP. Os termos “arquivo” e “segmento” são usados como sinônimos no presente documento a menos de especificação em contrário. No caso do HTTP, o segmento pode ser considerado como o corpo entidade de uma resposta de requisição HTTP.

[00074] Os termos “apresentação” e “item de conteúdo” são usados como sinônimos no presente documento. Em muitos exemplos, a apresentação é um áudio, vídeo, ou outras apresentações de mídia que possuem um tempo de reprodução ou “playout” definido, porém outras variações são possíveis.

[00075] Os termos “bloco” e “fragmento” são usados como sinônimos no presente documento a menos de especificação em contrário e de um modo geral se referem à menor agregação de dados que é indexada. Com base na indexação disponível, um cliente pode requisitar diferentes porções ou partes de um fragmento em diferentes requisições HTTP, ou pode requisitar um ou mais fragmentos consecutivos ou porções de fragmentos em uma requisição HTTP. No caso em que forem usados segmentos baseados no formato de arquivo de mídia de base ISO ou segmentos baseados no formato de arquivo 3GPP, um fragmento se refere tipicamente a um fragmento de filme definido como a combinação de uma caixa/box de header/cabeçalho de fragmento de filme (“moof”) e uma caixa/box de dados de mídia (“mdat”).

[00076] Neste documento, presume-se que uma rede que porta dados seja baseada em pacotes de modo a simplificar as presentes descrições, reconhecendo-se que, após a leitura da presente descrição, os técnicos na área podem aplicar modalidades da presente invenção aqui descritas a outros tipos de redes de transmissão, tais como redes de bit-stream contínua.

[00077] Neste documento, presume-se que os códigos FEC proporcionem proteção contra tempos de distribuição/transporte longos e variáveis dos dados, de modo a simplificar as presentes descrições, reconhecendo-se que, após a leitura da presente descrição, os técnicos na área podem aplicar modalidades da presente invenção aqui descritas a outros tipos de problemas de transmissão de dados, tais como uma deterioração de dados do tipo “bit-flip”. Como exemplo, sem o FEC, caso a última parte de um fragmento requisitado chegue muito mais tarde, ou apresente elevada variância em seu tempo de chegada em comparação a partes anteriores do fragmento, então o tempo de zapping do conteúdo pode ser elevado e variável, enquanto que pelo uso de FEC e requisições paralelas, somente a maioria dos dados requisitados para um fragmento deve chegar antes que ele possa ser recuperado, reduzindo desse modo o tempo de zapping do conteúdo e a variação do tempo de zapping do conteúdo. Na presente descrição, pode ser presumido que os dados a serem codificados (isto é, os dados fonte) foram separados ou repartidos em “símbolos” de igual comprimento, os quais podem possuir qualquer comprimento (até um único bit), porém os símbolos poderiam ser de diferentes comprimentos para diferentes partes dos dados, por exemplo diferentes tamanhos de símbolos poderiam ser utilizados para diferentes blocos de dados.

[00078] Na presente descrição, e para simplificar as descrições aqui apresentadas, é presumido que o FEC é aplicado a um “bloco” ou “fragmento” de dados em u instante, isto é, um “bloco” é um “bloco fonte” para propósitos de codificação e decodificação. Um dispositivo cliente pode usar a indexação de segmentos aqui descrita para auxiliar na determinação da estrutura de bloco fonte de um segmento. Os técnicos na área podem aplicar modalidades da presente invenção a outros tipos de estruturas de blocos fonte, por exemplo um bloco fonte pode ser uma parte de um fragmento, ou englobar um ou mais fragmentos ou partes de fragmentos.

[00079] Os códigos FEC considerados para uso com streaming por requisição de blocos são tipicamente códigos FEC sistemáticos, isto é, os símbolos fonte do bloco fonte podem ser incluídos como parte da codificação do bloco fonte e assim os símbolos fonte são transmitidos. Como notarão os técnicos na área, as modalidades aqui descritas se aplicam igualmente bem a 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, um certo número de símbolos de reparo, e a combinação de pelo menos alguns dos símbolos de reparo e fonte constitui os símbolos codificados que são enviados através do canal representando o bloco fonte. Alguns códigos FEC podem ser úteis para gerar eficientemente tantos símbolos de reparo quanto necessário, tais como “códigos aditivos de informações” ou “códigos fonte” e os exemplos de tais 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, tais como códigos Reed-Solomon, podem na prática gerar apenas um número limitado de símbolos de reparo para cada bloco fonte.

[00080] Em muitos de tais exemplos é presumido que um cliente está acoplado a um servidor de mídia ou a uma pluralidade de servidores de mídia e o cliente requisita mídia em streaming através de um canal ou uma pluralidade de canais a partir do servidor de mídia ou da pluralidade de servidores de mídia. No entanto, são também possíveis disposições de maior envolvimento

Exemplos de Benefícios

[00081] Com o streaming por requisição de blocos, o cliente de mídia mantém um acoplamento entre o timing de tais requisições de blocos e o timing da reprodução de mídia para o usuário. Tal modelo pode reter as vantagens do modelo de “download” acima descrito, evitando porém algumas das desvantagens que se originam no desacoplamento da reprodução de mídia do transporte/distribuição de mídia.. o modelo de streaming por requisição de blocos faz uso dos mecanismos de controle de congestionamento e taxa disponíveis nos protocolos de transporte, tais como o TCP, para assegurar que a máxima amplitude de banda disponível seja utilizada para dados de mídia. Adicionalmente, a divisão das apresentações de mídia em blocos permitem que cada bloco de dados de mídia codificados seja selecionado a partir de um conjunto de múltiplas codificações disponíveis.

[00082] Tal seleção pode se basear em vários critérios, incluindo a compatibilização da taxa de dados de mídia à amplitude de banda disponível, mesmo quando a amplitude de banda disponível está se modificando ao longo do tempo, compatibilização da resolução dos mídia ou da complexidade de decodificação às capacidades ou configuração do cliente, ou compatibilização com as preferências do usuário, tais como o idioma. A seleção pode também incluir o download e a apresentação de componentes auxiliares, tais como componentes de acessibilidade, legenda oculta, legendas, vídeo de linguagem de sinais e assim por diante. Os exemplos de sistemas existentes que usam o modelo de streaming por requisição de blocos incluem o Move Networks™, o Microsoft Smooth Streaming e o Apple iPhone™ Streaming Protocol.

[00083] Comumente, cada bloco de dados de mídia pode estar armazenado em um servidor na forma de um arquivo individual, e então um protocolo, tal como o HTTP, é usado em conjunto com um software de servidor HTTP executado no servidor, para requisitar o arquivo como uma unidade. Tipicamente, o cliente é provido com arquivos de metadados, os quais podem estar, por exemplo, no formato XML (Extensible Markup Language), ou em formato de texto de lista de reprodução ou “playlist”, ou em formato binário, os quais descrevem características da apresentação de mídia, tais como codificações disponíveis (por exemplo, a amplitude de banda requerida, resoluções, parâmetros de codificação, tipo de mídia, idioma), tipicamente designados como “representações” no presente documento, e a maneira pela qual as codificações foram divididas em blocos. Como exemplo, os metadados podem incluir um URL (Uniform/Universal Resource Locator) para cada bloco. O URL por si pode prover um esquema tal como ser precedido pelo string/seqüência “http://” para indicar que o protocolo que deve ser usado para acessar o recurso documentado é o HTTP. Outro exemplo é “ftp://” para indicar que o protocolo que deve ser usado é o FTP.

[00084] Em outros sistemas, por exemplo, os blocos de mídia podem ser construídos “em percurso” pelo servidor em resposta a uma requisição proveniente do cliente que indica a parte da apresentação de mídia, no tempo, que é requisitada. Como exemplo, no caso do HTTP com o esquema “http://”, a execução da requisição de tal URL provê uma resposta a requisição que contém alguns dados específicos no corpo da entidade de tal resposta a requisição. A implementação na rede sobre como gerar tal resposta a requisição pode ser bem diferente, dependendo da implementação do servidor que serve a tais requisições.

[00085] Tipicamente, cada bloco pode ser decodificado de forma independente. Como exemplo, no caso de mídia de vídeo, cada bloco pode se iniciar com um “ponto de busca” ou “seek point”. Em alguns esquemas de codificação, um ponto de busca é designado como um “ponto de acesso aleatório” ou RAP (Random Access Point), 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 se inicia em um quadro IDR (Independent Data Refresh - atualização de dados independente), no caso da vídeo codificação H.264, apesar de nem todos IDRs poderem ser designados como um ponto de busca. Um ponto de busca é uma posição em mídia de vídeo (ou outro) em que um decodificador pode iniciar a decodificação sem requerer quaisquer dados a respeito de quadros, ou dados, ou amostras anteriores, tal como poderia ser o caso em que um quadro ou amostra que está sendo decodificado foi codificado não de uma forma independente, porém, por exemplo, como a diferença entre o quadro atual/corrente e o quadro anterior.

[00086] Uma preocupação em tais sistemas pode ser a capacidade de iniciar a reprodução de uma corrente/stream/fluxo, por exemplo decodificar e apresentar fluxos de áudio e vídeo recebidos usando- se um computador pessoal e apresentação do vídeo em um monitor/tela de computador e reproduzir o áudio através de alto falantes embutidos, ou, como outro exemplo, decodificar e apresentar fluxos de áudio e vídeo recebidos usando-se um “top set box” ou decodificador e apresentação do vídeo em um dispositivo de display de televisão e reprodução do áudio através de um sistema estéreo. Uma preocupação principal pode ser a de minimizar o retardo entre quando um usuário decide assistir a um novo conteúdo recebido na forma de um fluxo/stream e enceta uma ação que expressa tal decisão, por exemplo o usuário clica em um link no interior de uma janela de um navegados/browser, ou no botão/tecla “play”/reproduzir de um dispositivo de controle remoto e, quando se inicia a reprodução do conteúdo na tela do usuário, a seguir designado como o “instante de zapping do conteúdo”. Cada uma de tais preocupações pode ser atacada por elementos do sistema ampliado aqui descrito.

[00087] Um exemplo de “zapping” de conteúdo ocorre quando um usuário está assistindo um primeiro conteúdo distribuído através de um primeiro fluxo/stream e a seguir o usuário decide assistir um segundo conteúdo distribuído através de um segundo fluxo/stream e inicia uma ação para começar a assistir o segundo conteúdo. O segundo fluxo pode ser enviado a partir do mesmo conjunto que o primeiro fluxo ou de um conjunto diferente de servidores. Como outro exemplo de zapping de conteúdo, um usuário pode estar visitando um website e decide começar a assistir um primeiro conteúdo transportado por meio de um primeiro fluxo 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 a partir do início, mas sim a partir de um certo momento dentro do fluxo. O usuário indica a seu dispositivo cliente que deseja que ele procure uma posição no tempo e o usuário poderia esperar que o instante selecionado seja reproduzido instantaneamente. A minimização do tempo de zapping de conteúdos é importante para a reprodução de vídeos de modo a permitir aos usuários uma experiência de alta qualidade de “surfar” os conteúdos ao procurar e amostrar uma ampla gama de conteúdos disponíveis.

[00088] Recentemente, se tornou prática comum considerar o uso de códigos de correção antecipada de erros (FEC) para a proteção de mídia em streaming durante a transmissão. Quando enviado através de uma rede de pacotes, exemplos da qual incluem a Internet e redes wireless tais como aquelas padronizadas por grupos tais como o 3GPP, 3GPP2 e DVB, o fluxo/stream fonte é colocado em pacotes a medida que é gerado ou tornado disponível, os pacotes podendo ser usados para portar o fluxo ou conteúdo fonte na ordem em que ele é gerado ou tornado disponível para os receptores.

[00089] Em uma típica aplicação de códigos FEC para tais tipos de situações, um codificador pode usar um código FEC na criação de pacotes de reparo, os quais são a seguir enviados em adição aos pacotes fonte originais contendo o fluxo fonte. Os pacotes de reparo possuem uma propriedade de que, quando ocorre uma perda de um pacote fonte, os pacotes de reparo recebidos podem ser usados para recuperar os dados contidos nos pacotes fonte perdidos. Os pacotes de reparo podem ser usados para recuperar o conteúdo de pacotes fonte perdidos que são inteiramente perdidos, porém poderiam também ser usados para recuperar pacotes parcialmente perdidos, sejam pacotes de reparo inteiramente recebidos ou mesmo pacotes de reparado parcialmente recebidos. Dessa forma, pacotes de reparo total ou parcialmente recebidos podem ser usados para recuperar pacotes fonte total ou parcialmente perdidos.

[00090] Em mais outros exemplos, podem ocorrer outros tipos de corrupção para os dados enviados, por exemplo valores de bits podem estar trocados, e portanto os pacotes de reparo podem ser usados para corrigir tal corrupção e prover recuperação tão acurada quanto possível dos pacotes fonte. Como outros exemplos, o fluxo fonte não é necessariamente enviado em pacotes individuais, podendo em lugar disto ser enviado, por exemplo, na forma de um fluxo ou stream contínuo.

[00091] Existem vários exemplos de códigos FEC que podem ser usados para prover proteção a um fluxo fonte. Os códigos Reed-Solomon são códigos bem conhecidos para correção de apagamentos e erros nos sistemas de comunicação. Para a correção de apagamentos em, por exemplo, redes de dados em pacotes, uma eficiente implementação bem conhecida de códigos Reed-Solomon utiliza matrizes Cauchy ou Vandermonde, tal como descrito por L. Rizzo em “Effective Erasure Codes for Reliable Computer Communication Protocols”, Computer Communication Review, 27(2):24-36 (abril, 1997) (a seguir designado como “Rizzo”) e por Bloemer et al. Em “An XOR-Based Erasure-Resilient Coding Scheme”, Technical Report TR-95-48, International Computer Science Institute, Berkeley, California (1995) (a seguir designado como “XOR-Reed-Solomon”) ou em outras publicações.

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

[00093] Exemplos do processo de decodificação FEC para variantes de códigos Reed-Solomon estão descritos em Rizzo e XOR-Reed-Solomon. Em tais exemplos, a decodificação pode ser aplicada após ter sido recebida uma quantidade suficiente de pacotes de reparo e fonte. O processo de decodificação pode ser trabalhoso em termos de computação e, dependendo dos recursos disponíveis na CPU, isto pode tomar uma quantidade considerável de tempo para se completar em relação à duração de tempo abrangida pelos mídia no bloco. O receptor pode levar em consideração tal duração de tempo necessária para a decodificação ao calcular o retardo necessário entre o início da recepção do fluxo de mídia e a reprodução dos mídia. Tal retardo devido à decodificação é percebido pelo usuário como um retardo entre sua requisição por um fluxo de mídia específico e o início da reprodução. É portanto desejável a minimização de tal retardo.

[00094] Em várias aplicações, os pacotes podem ser adicionalmente subdivididos em símbolos sobre os quais é aplicado o processo FEC. Um pacote pode conter um ou mais símbolos (ou menos de um símbolo, porém usualmente os símbolos não são divididos através de grupos de pacotes a menos que se saiba que as condições de erros entre grupos de pacotes estão altamente correlacionadas). Um símbolo pode possuir qualquer tamanho, porém freqüentemente o tamanho de um símbolo é no máximo igual ao tamanho do pacote. Os símbolos fonte são aqueles que codificam os dados que devem ser transmitidos. Os símbolos de reparo são símbolos gerados a partir de símbolos fonte, direta ou indiretamente, e que são adicionados aos símbolos fonte (isto é, os dados a serem transmitidos podem ser inteiramente recuperados caso todos os símbolos fonte estejam disponíveis e nenhum dos símbolos de reparo estejam disponíveis.

[00095] Alguns códigos FEC podem ser baseados em blocos, pelo fato de que as operações de codificação dependem dos símbolos que estão em um bloco e podem ser independentes dos símbolos que não estão em tal bloco. Com a codificação baseada em blocos, um codificador FEC pode gerar símbolos de reparo para um bloco a partir dos símbolos fonte em tal bloco, a seguir passar para o próximo bloco e não necessita consultar símbolos fonte a não ser aqueles do bloco corrente que está sendo codificado. Em uma transmissão, um bloco fonte contendo símbolos fonte pode ser representado por um bloco codificado compreendendo símbolos codificados (os quais poderiam ser símbolos alguns fonte, alguns símbolos de repara, ou ambos). Com a presença de símbolos de reparo, nem todos os símbolos fonte são necessários em cada bloco codificado.

[00096] Para alguns códigos FEC, notavelmente códigos Reed-Solomon, o tempo de codificação e decodificação pode se tornar impraticável a medida que cresce o número de símbolos codificados por bloco fonte. Dessa forma, na prática, existe freqüentemente um limite superior prático (255 constitui um limite prático aproximado para algumas aplicações) para o número total de símbolos codificados que podem ser gerados por bloco fonte, especialmente em um caso típico em que o processo de codificação ou decodificação Reed-Solomon é efetuado por hardware padrão, por exemplo os processos MPE- FEC que utilizam códigos Reed-Solomon incluídos como parte da norma DVB-H para proteção de fluxos contra perda de pacotes são implementados em hardware especializado em um telefone celular que está limitado a 255 símbolos codificados Reed-Solomon totais por bloco fonte. Dado que os símbolos devem amiúde ser colocados em cargas úteis/payloads de pacotes separados, isto impõe um limite superior prático sobre o comprimento máximo do bloco fonte sendo codificado. Como exemplo, caso a payload/carga útil do pacote esteja limitada a 1024 bytes ou menos e cada pacote porta um símbolo codificado, então um bloco fonte codificado pode possuir no máximo 255 kilobytes, constituindo este, naturalmente, um limite superior sobre o tamanho do próprio bloco fonte.

[00097] Outras considerações, tais como a capacidade de decodificar os blocos fonte com rapidez suficiente para acompanhar a taxa de streaming, para minimizar a latência de decodificação introduzida pela decodificação FEC e para usar apenas uma pequena fração da CPU disponível no dispositivo receptor a qualquer momento no tempo durante a decodificação FEC, são atendidas por elementos aqui descritos, bem como lidar com

[00098] A necessidade de proporcionar uma solução de transporte/distribuição de streaming estável e escalonável que permita aos componentes do sistema falhar sem afetar adversamente a qualidade dos fluxos/streams levados aos receptores.

[00099] Um sistema de streaming por requisição de blocos deve dar suporte a 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 dos parâmetros das codificações de mídia, tais como taxa de bits, resolução, razão de aspecto, CODECs de áudio ou vídeo ou parâmetros de CODEC de mudanças em outros metadados tais como URLs associados aos arquivos de conteúdo. Tais mudanças podem ser necessárias por várias razões, incluindo a edição/união de conteúdos provenientes de diferentes fontes, tais como propagandas ou diferentes segmentos de uma apresentação maior, modificação de URLs ou outros parâmetros que se tornem necessárias como resultado de mudanças na infraestrutura servidora por exemplo devido a mudanças de configuração, falhas de equipamentos, ou recuperação de falhas de equipamentos, ou outras razões.

[000100]Existem métodos em que uma apresentação pode ser controlada por um arquivo do tipo playlist continuamente atualizado. Dado que tal arquivo é atualizado continuamente, então pelo menos parte das mudanças acima podem ser efetuadas dentro de tais atualizações. Uma desvantagem de um método convencional é a de que os dispositivos cliente devem recuperar continuamente, o que é conhecido como “polling” ou “pesquisar”, o arquivo de playlist exercendo uma carga sobre a infraestrutura de serviço e pelo fato de que tal arquivo não pode ser colocado em cache por tempo mais longo do que o intervalo de atualização, tornando a tarefa para a infraestrutura servidora muito mais difícil. Isto é solucionado pelos elementos aqui descritos, de forma a que as atualizações do tipo acima descrito são providas sem a necessidade de pesquisas contínuas pelos clientes quanto ao arquivo de metadados.

[000101]Outro problema, especialmente nos serviços “ao vivo”, tipicamente conhecidos pela distribuição em broadcast, consiste da incapacidade do usuário de assistir a conteúdos que foram irradiados em broadcast antes que o usuário começasse a assistir ao programa. Tipicamente, as gravações pessoais locais consomem armazenamento local desnecessário, ou não é possível dado que o cliente não estava sintonizado no programa, ou por ser proibido por regras de proteção a conteúdo. A gravação na rede e a audiência temporalmente deslocada são preferidas, porém requerem conexões individuais do usuário ao servidor e um protocolo de transporte e infraestrutura separados daqueles dos serviços “ao vivo”, resultando em infraestrutura duplicada e custos significativos para o servidor. Isto também é solucionado pelos elementos aqui descritos.

Visão Geral do Sistema

[000102]Uma modalidade da invenção será descrita por referência à Figura 1, que mostra um diagrama simplificado de um sistema de streaming por requisição de blocos de acordo com a presente invenção.

[000103]Na Figura 1, está ilustrado um sistema de streaming em blocos 100, compreendendo a infraestrutura servidora de blocos (BSI) 101, que por sua vez compreende um sistema de ingestão 103 para ingestão de conteúdo 102, preparação de tal conteúdo e seu empacotamento para serviço por um servidor de streaming HTTP 104 por armazenamento do mesmo em um armazenamento de conteúdo 104. Tal como ilustrado, o sistema 100 poderia incluir também um cache HTTP 106. Em operação, um cliente 108, tal como um cliente de streaming HTTP, envia requisições 112 para o servidor de streaming HTTP 104 e recebe respostas 114 a partir do servidor de streaming HTTP 104 ou cache HTTP 106. Em cada caso, os elementos apresentados na Figura 1 poderiam ser implementados, pelo menos em parte, em software, o mesmo compreendendo um código de programa que é executado em um processador ou outros componentes eletrônicos.

[000104]O conteúdo pode incluir filmes, áudio, vídeo 2D/planos, vídeos 3D, outros tipos de vídeo, imagens, texto temporizado, metadados temporizados ou similares. Alguns conteúdos podem envolver dados que devem ser apresentados ou consumidos de modo temporizado, tais como dados para a apresentação de informações auxiliares (identificação da estação, propaganda/anúncios, cotações de ações, seqüências Flash™ e assim por diante).

[000105]Tal como ilustrado na Figura 2, blocos de mídia podem ser armazenados em uma estrutura servidora de blocos 101(1), a qual poderia ser, por exemplo, um servidor HTTP, um dispositivo de rede de transporte/distribuição de conteúdo, um proxy HTTP, um servidor ou proxy FTP, ou algum outro sistema ou servidor de mídia. A infraestrutura servidora de blocos 101(1) está conectada a uma rede 122, que poderia ser, por exemplo,uma rede de protocolo Internet (IP) tal como a Internet. Um sistema cliente de streaming de requisição de blocos é apresentado possuindo seis componentes funcionais, quais sejam um seletor de blocos 123, provido com os metadados acima descritos e efetuando uma função para seleção de blocos ou blocos parciais a serem requisitados dentre a pluralidade de blocos disponíveis indicados pelos metadados, um requisitador de blocos 124, que recebe instruções de requisição provenientes do seletor de blocos 123 e efetua as operações necessárias para envio de uma requisição para o bloco especificado, partes de um bloco, ou múltiplos blocos, para a infraestrutura servidora de blocos 101(1) através da rede 122 e para receber em resposta os dados compreendendo o bloco, bem como um buffer ou acumulador de blocos 125, um monitor de buffer 126, um decodificador de mídia 127 e um ou mais transdutores de mídia 128 que facilitam o consumo de mídia.

[000106]Os dados em blocos recebidos pelo requisitador de blocos 124 são passados para armazenamento temporário para o buffer de blocos 125, que armazena os dados de mídia. Alternativamente, os dados em blocos recebidos podem ser armazenados diretamente no buffer de blocos 125, tal como ilustrado na Figura 1. O decodificador de mídia 127 é provido com dados de mídia pelo buffer de blocos 125 e efetua as transformações nos dados que sejam necessárias para prover uma alimentação adequada para os transdutores de mídia 128, os quais apresentam os mídia em uma forma adequada para o usuário ou outro tipo de consumo. Os exemplos de transdutores de mídia incluem dispositivos de display visual, tais como aqueles encontrados em telefones celulares, sistemas de computadores, ou televisores, e podem incluir também dispositivos apresentadores de áudio, tais como alto falantes ou fones de ouvido.

[000107]Um exemplo de um decodificador de mídia seria uma função que transforma dados no formato descrito na norma de codificação de vídeo H.264 para representações analógicas ou digitais de quadros de vídeo, tais como um mapa de pixels no formato YUV com os associados timestamps/marcas de tempo de apresentação para cada quadro ou amostra.

[000108]O monitor de buffer 126 recebe informações concernentes aos conteúdos do buffer de blocos 125 e, com base em tais informações e possivelmente outras informações, provê alimentação para o seletor de blocos 123, o qual é usado para determinar a seleção de blocos a requisitar, tal como é aqui descrito.

[000109]Na terminologia aqui utilizada, cada bloco possui um “playout time” ou “tempo de apresentação/reprodução” ou “duração” que representa a quantidade de tempo necessária para o receptor reproduzir os mídia incluídos em tal bloco na velocidade normal. Em alguns casos, a reprodução dos mídia dentro de um bloco pode depender de já se ter recebido os dados de blocos anteriores. Em raros casos, a reprodução de alguns dos mídia em um bloco pode depender em um bloco subseqüente, caso este em que o tempo de playout para o bloco é definido com relação aos mídia que podem ser reproduzidos dentro do bloco sem referência ao bloco subseqüente, e o tempo de reprodução para o bloco subseqüente é aumentado pelo tempo de reprodução dos mídia em tal bloco que podem ser reproduzidos somente após a recepção do bloco subseqüente. Dado que a inclusão de mídia em um bloco que depende de blocos subseqüentes é um caso raro, no restante da presente descrição será presumido que os mídia em um bloco não dependem de blocos subseqüentes, porém deve ser notado que os técnicos na área saberão que tal variante pode ser facilmente adicionada às modalidades descritas abaixo.

[000110]O receptor pode possuir controles tais como “pause” (pausa), “fast forward” (reprodução rápida), “reverse” (retrocesso) e assim por diante, que podem resultar no bloco ser consumido pela reprodução em uma taxa/velocidade diferente, porém se o receptor puder obter e decodificar cada seqüência consecutiva de blocos em um tempo total igual ou menor do que o tempo total de reprodução excluindo o último bloco na seqüência então o receptor pode apresentar os mídia para o usuário sem parar ou “estolar” (stalling). Em algumas descrições no presente documento, uma posição particular no fluxo de mídia é designada como um “tempo” particular no mídia, correspondendo ao tempo que teria decorrido entre o início da reprodução dos mídia e o instante em que a posição particular no fluxo de vídeo é alcançada. O tempo ou posição em um fluxo de mídia é um conceito convencional. Como exemplo, quando o fluxo de vídeo compreende 24 quadros por segundo, pode ser dito que o primeiro quadro possui uma posição ou tempo de t = 0,0 segundo e o 241° quadro uma posição de tempo de t = 10,0 segundos. Naturalmente, em um fluxo de vídeo baseado em quadros, a posição ou o tempo não necessitam ser contínuos, dado que cada um dos bits no fluxo do primeiro bit do 241° quadro até imediatamente antes do primeiro bit do 242° quadro poderiam todos possuir o mesmo valor de tempo.

[000111]Adotando-se a terminologia acima, um sistema de streaming por requisição de blocos (BRSS) compreende um ou mais clientes que efetuam requisições para um ou mais servidores de conteúdo (por exemplo, servidores HTTP, servidores FTP e assim por diante). Um sistema de ingestão compreende um ou mais processadores de ingestão, em que um processador de ingestão recebe conteúdo (em tempo real ou não), processa o conteúdo para uso pelo BRSS e o armazena em um armazenamento acessível para os servidores de conteúdo, possivelmente em conjunto com metadados gerados pelo processador de ingestão.

[000112]O BRSS pode também conter caches de conteúdo que se coordenam com os servidores de conteúdo. Os servidores de conteúdo e caches de conteúdo podem ser servidores HTTP e caches HTTP convencionais que recebem requisições para arquivos ou segmentos na forma de requisições HTTP que incluem um URL, e podem também incluir uma gama de bytes, de modo a requisitar menos do que a totalidade do arquivo ou segmento indicado pelo URL. Os clientes poderiam incluir um cliente HTTP convencional que efetua requisições de servidores HTTP e gerencia as respostas para tais requisições, em que o cliente HTTP é acionado por um sistema de cliente novo que formula requisições, as passa para o cliente HTTP, obtém respostas a partir do cliente HTTP e processa estas (ou armazena, transforma, etc.) de modo a prove-las para um reprodutor de apresentação para reprodução por um dispositivo cliente. Tipicamente, o sistema cliente não sabe antecipadamente quais mídia serão necessários (dado que as necessidades podem depender de alimentações do usuário, mudanças nas alimentações do usuário e assim por diante), portanto ele é descrito como um sistema de “streaming” pelo fato de que os mídia são consumidos tão logo são recebidos, ou logo após isso. Como resultado, os retardos de resposta e restrições de amplitude de banda podem causar retardos em uma apresentação, tais como causando uma pausa em uma apresentação enquanto o fluxo alcança o ponto em que o usuário está consumindo a apresentação.

[000113]Para prover uma apresentação que seja percebida como sendo de boa qualidade, vários detalhes podem ser implementados no BRSS, seja na ponta do cliente, na ponta de ingestão, ou ambas. Em alguns casos os detalhes que são implementados o são em consideração da, e para gerenciar à, interface cliente - servidor na rede. Em algumas modalidades, tanto o sistema cliente como o sistema de ingestão estão informados sobre a inovação ou ampliação, enquanto que em outras modalidades apenas uma das pontas está informada sobre a inovação. Em tais casos, todo o sistema se beneficia com a inovação, mesmo que uma das pontas não esteja informada sobre ela, enquanto que em outras o benefício só se realiza caso ambas as pontas estejam informadas sobre a inovação, porém quando uma das pontas não está informada ela ainda opera sem falhar.

[000114]Tal como ilustrado na Figura 3, o sistema de ingestão pode ser implementado na forma de 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 levar o sistema a efetuar um ou mais dos métodos aqui descritos. O sistema pode ser montado na forma de uma máquina específica como um computador. O sistema pode ser um computador servidor, um computador pessoal (PC), ou qualquer sistema capaz de executar um conjunto de instruções (seqüencialmente ou de outra forma) que especifique as ações a serem efetuadas pelo sistema. Além disso, apesar de apenas um sistema ser ilustrado, o termo “sistema” deve também ser considerado como incluindo qualquer coletânea de sistemas que individualmente ou em conjunto executam um conjunto (ou múltiplos conjuntos) de instruções para efetuar qualquer um ou mais dos métodos aqui descritos.

[000115]O sistema de ingestão pode incluir o processador de ingestão 302 (por exemplo, uma unidade central de processamento - CPU - central, uma memória 304 que pode armazenar um código de programa durante a execução e armazenamento em disco 306, todos estes se comunicando entre si por meio de um cabeamento/barramento/bus 300. o sistema pode incluir também uma unidade de display de vídeo 308 (por exemplo, um display de cristal líquido (LCD) ou tubo de raios catódicos (CRT)). O sistema pode compreender também um dispositivo de alimentação alfa numérico 310 (por exemplo, um teclado) e um dispositivo de interface de rede 312 para receber conteúdo fonte e emitir/distribuir armazenamento de conteúdo.

[000116]A unidade de armazenamento em disco 306 pode incluir um meio para leitura por máquina no qual podem ser armazenados um ou mais conjuntos de instruções (por exemplo, software) incorporando quaisquer um ou mais dos métodos ou funções aqui descritos. As instruções podem também residir, completa ou pelo menos parcialmente, dentro da memória 304 e/ou no interior 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 meios para leitura por máquina.

[000117]Tal como ilustrado na Figura 4, o sistema cliente pode ser implementado na forma de uma combinação de componentes de hardware e software, de acordo com várias modalidades.

[000118]O sistema cliente pode compreender um conjunto de instruções que podem ser executadas para levar o sistema a efetuar um ou mais dos métodos aqui descritos. O sistema pode ser montado na forma de uma máquina específica como um computador. O sistema pode ser um computador servidor, um computador pessoal (PC), ou qualquer sistema capaz de executar um conjunto de instruções (seqüencialmente ou de outra forma) que especifique as ações a serem efetuadas pelo sistema. Além disso, apesar de apenas um sistema ser ilustrado, o termo “sistema” deve também ser considerado como incluindo qualquer coletânea de sistemas que individualmente ou em conjunto executam um conjunto (ou múltiplos conjuntos) de instruções para efetuar qualquer um ou mais dos métodos aqui descritos.

[000119]O sistema cliente pode incluir o processador cliente 402 (por exemplo, uma unidade central de processamento - CPU - central), uma memória 404 que pode armazenar um código de programa durante a execução e armazenamento em disco 406, todos estes se comunicando entre si por meio de um cabeamento/barramento/bus 400. O sistema pode incluir também uma unidade de display de vídeo 408 (por exemplo, um display de cristal líquido (LCD) ou tubo de raios catódicos (CRT)). O sistema pode compreender também um dispositivo de alimentação alfa numérico 410 (por exemplo, um teclado) e um dispositivo de interface de rede 412 para enviar requisições e receber respostas.

[000120]A unidade de armazenamento em disco 406 pode incluir um meio para leitura por máquina no qual podem ser armazenados um ou mais conjuntos de instruções (por exemplo, software) incorporando quaisquer um ou mais dos métodos ou funções aqui descritos. As instruções podem também residir, completa ou pelo menos parcialmente, dentro da memória 404 e/ou no interior do processador cliente 402 durante a execução das mesmas pelo sistema, com a memória 404 e o processador cliente 402 também constituindo meios para leitura por máquina.

Uso do Formato de Arquivo 3GPP

[000121]O formato de arquivo 3GPP ou qualquer outro arquivo baseado no formato de arquivo de mídia de base ISO, tal como o formato de arquivo MP4, ou o formato de arquivo 3GPP2, podem ser usados como o formato de contenção para streaming HTTP com as características que se seguem. Um índice de segmento pode ser incluído em cada segmento para sinalizar offsets de tempo e faixas de bytes, de tal forma que o cliente possa baixar/download as peças apropriadas de arquivos ou segmentos de mídia, conforme necessário. O timing global de apresentação de toda a apresentação de mídia e o timing local dentro de cada segmento de mídia ou arquivo 3GPP podem estar precisamente alinhados. As pistas/tracks através das representações podem também estar alinhadas através da designação de cada uma delas para a linha de tempo/timeline global, de tal forma que a comutação através da representação possa ocorrer sem interrupções e a apresentação conjunta de componentes de mídia em diferentes representações possa ser síncrona.

[000122]O formato de arquivo pode conter um perfil para Adaptive Streaming (streaming adaptável) com as propriedades que se seguem. Todos os dados de filmes podem estar contidos em fragmentos de filmes - a caixa/box “moov” não pode conter quaisquer informações de amostras. Os dados de amostras de áudio e vídeo podem ser intercalados, com exigências similares àquelas do perfil de download progressivo tal como especificado na TS 26.244. A caixa “moov” pode ser posicionada no início do arquivo, seguida por dados de offset de fragmento, também designado como um índice de segmento, contendo informações de offset em faixas de bytes e tempo para cada fragmento, ou pelo menos um subconjunto de fragmentos no segmento que o contém.

[000123]Pode também ser possível que a descrição de apresentação de mídia faça referência a arquivos que se seguem ao perfil de download progressivo existente. Em tal caso o cliente pode usar a descrição de apresentação de mídia simplesmente para selecionar a versão alternativa apropriada dentre múltiplas versões disponíveis. Os clientes podem também usar requisições de obtenção parcial HTTP com arquivos que estejam de acordo com o perfil de download progressivo para requisitar subconjuntos de cada versão alternativa e desse modo implementar uma forma menos eficiente de streaming adaptável. Em tal caso as diferentes representações contendo os mídia no perfil de download adaptável podem ainda aderir a uma linha de tempo global comum de modo a permitir comutação sem interrupções através das representações.

Visão Geral dos Métodos Avançados

[000124] Nas seções que se seguem são descritos os métodos para os sistemas de bloqueio aprimorados de solicitação de streaming. Deve ficar claro que alguns destes melhoramentos podem ser utilizados com ou sem outros destes melhoramentos, dependendo das necessidades da aplicação. Na operação geral, um receptor faz pedidos a um servidor ou outro transmissor para blocos específicos ou porções de blocos de dados. Arquivos, também chamadas de segmentos, podem conter vários blocos e estão associados com uma representação de uma apresentação dos mídia.

[000125]De preferência, são geradas informações de indexação, o que é também chamado de "indexação de segmento" ou "mapa de segmento" que provê um mapeamento que fornece desde os tempos de playout ou decodificação a offsets de bytes de blocos ou fragmentos correspondentes dentro de um segmento. Tal indexação de segmentos pode ser incluído dentro do segmento, tipicamente no início do segmento (pelo menos parte do mapa de segmento se encontra no início) e é amiúde pequeno. O índice de segmento pode também ser fornecido em um arquivo ou índice de segmento separado. Especialmente nos casos em que o índice de segmento está contido no segmento, o receptor pode baixar parte ou a totalidade de tal mapa de segmentos de forma rápida e subseqüentemente utilizar este para determinar o mapeamento entre deslocamentos ou offsets de tempo e as correspondentes posições de byte de fragmentos associados a esses deslocamentos de tempo dentro do arquivo.

[000126]Um receptor pode usar o offset/deslocamento de bytes para solicitar dados a partir dos fragmentos associados a deslocamentos de tempo específicos, sem ser obrigado a baixar todos os dados associados com outros fragmentos não associados com os deslocamentos de tempo de interesse. Desta forma, o mapa de segmentos ou indexação de segmentos pode melhorar significativamente a capacidade de um receptor para acessar diretamente as porções do segmento que são relevantes para os deslocamentos de tempo atuais de interesse, com os benefícios incluindo melhores tempos de zapping de conteúdo, a capacidade de mudar rapidamente de uma representação para outra a medida que variam as condições da rede, e redução do desperdício de recursos de rede com o download de mídia que não é reproduzido em um receptor.

[000127]No caso m que é considerada a comutação de uma representação (aqui referido como “a representação da qual se comuta”) para uma outra representação (aqui referida como "a representação para a qual se comuta”), o índice de segmento pode também ser usado para identificar o tempo ou instante inicial de um ponto de acesso aleatório representação para a qual se muda para identificar a quantidade de dados a ser solicitada na representação da qual se comuta para assegurar que comutação sem interrupções seja possibilitada no sentido de que a mídia na representação da qual se muda seja baixada até um instante de apresentação de tal forma que a reprodução da qual se muda seja baixada até um instante de apresentação tal que a reprodução da representação para a qual se muda possa iniciar sem interrupções a partir do ponto de acesso aleatório.

[000128]Tais blocos representam segmentos da mídia de vídeo ou outros mídia/meios de comunicação que o receptor requisitante necessita para gerar a saída/emissão para o usuário do receptor. O receptor dos meios de comunicação pode ser um dispositivo de cliente, tal como quando o receptor recebe o conteúdo a partir de um servidor que transmite o conteúdo. Os exemplos incluem set-top boxes ou “decodificadores”, computadores, consoles de jogos, televisores especialmente equipados, dispositivos portáteis, telefones celulares especialmente equipados, ou de outros receptores clientes.

[000129] São aqui descritos vários métodos avançados de gerenciamento de buffer. Como exemplo, um método de gerenciamento de buffer permite aos clientes solicitar blocos da mais alta qualidade de mídia que podem ser recebidos em tempo para serem reproduzidos com continuidade. Uma característica de tamanho variável de blocos melhora a eficiência de compressão. A capacidade de se ter várias conexões para a transmissão de blocos para o dispositivo solicitante enquanto se limita a freqüência das requisições/pedidos proporciona um desempenho melhorado de transmissão. Blocos parcialmente recebidos de dados podem ser usados para continuar a apresentação dos mídia/meios de comunicação. Uma conexão pode ser reutilizada para múltiplos blocos sem obrigar a comprometer a conexão de início com um determinado conjunto de blocos. A consistência na seleção de servidores dentre vários possíveis servidores de vários clientes é melhorada, o que reduz a freqüência de conteúdo duplicado em servidores próximos e aumenta a probabilidade de que um servidor conter um arquivo completo. Os clientes podem solicitar blocos de mídia com base em metadados (tais como codificações de mídia disponíveis) que estão incorporados nos URLs para os arquivos contendo os blocos de mídia. Um sistema pode proporcionar o cálculo e minimização da quantidade de tempo de acumulação/buffer necessária antes que a reprodução do conteúdo possa começar sem incorrer em subseqüentes pausas na reprodução dos meios de comunicação. A amplitude de banda disponível pode ser partilhada entre vários blocos de mídia, ajustada a medida que o instante de reprodução de cada bloco se aproxima, de modo que, caso necessário, uma parte maior da largura de banda disponível possa ser alocada para o bloco com o tempo de reprodução mais próximo.

[000130]O streaming HTTP pode empregar metadados. Os metadados no nível de apresentação incluem, por exemplo, a duração do fluxo, codificações disponíveis (bitrates, codecs, resoluções espaciais, taxas de quadros, linguagem/idioma, tipos de mídia), pointers/ponteiros para metadados de fluxo para cada codificação e proteção de conteúdo (informações de gerenciamento de direitos digitais (DRM)). Os metadados de fluxo podem ser URLs para os arquivos de segmento.

[000131]Os metadados de segmentos podem incluir informações de faixa/intervalo de bytes contra informações de tempo para os pedidos/requisições dentro de um segmento, e identificação de pontos de acesso aleatório (RAPs) ou outros pontos de procura/busca, em que parte ou a totalidade de tais informações podem fazer parte de uma indexação de segmentos ou mapa de segmentos.

[000132]Os fluxos/streams podem incluir várias codificações do mesmo conteúdo. Cada codificação pode então ser dividida em segmentos em que cada segmento corresponde a uma unidade de armazenamento ou arquivo. No caso de HTTP, um segmento é tipicamente um recurso que pode ser referenciado por um URL e a requisição de tal URL resulta na resposta/retorno do segmento como o corpo da entidade da mensagem de resposta ao pedido. Os segmentos podem compreender múltiplos grupos de imagens (GOPs). Cada GOP pode ainda compreender múltiplos fragmentos onde a indexação do segmento fornece informações de tempo/offset ou deslocamento de bytes para cada fragmento, isto é, a unidade de indexação é um fragmento.

[000133]Os fragmentos ou porções de fragmentos podem ser solicitados através de conexões TCP paralelas para aumentar o rendimento ou capacidade de transmissão/throughput. Isto pode atenuar os problemas que surgem quando do compartilhamento de conexões em um link estrangulado ou quando as conexões são perdidos devido ao congestionamento, aumentando assim a velocidade e confiabilidade de entrega em geral, o que pode melhorar substancialmente a velocidade e a confiabilidade do tempo de zapping de conteúdo. A amplitude de banda pode ser negociado trocada por latência por requisição exagerada, mas cuidados devem ser tomados para evitar fazer pedidos por segmentos demasiado distantes no futuro, o que pode aumentar o risco de fome falta de conteúdo.

[000134]Múltiplas solicitações por segmentos ao mesmo servidor pode ser encadeadas/alinhadas em pipeline (efetuar o pedido seguinte, antes que a requisição atual seja completamente atendida) para evitar atrasos repetitivos de inicialização do TCP. Os pedidos de fragmentos consecutivos podem ser agregados em uma única requisição.

[000135]Alguns CDNs preferem arquivos grandes e podem desencadear recuperações secundárias/em background de todo um arquivo a partir de um servidor de origem ao observar pela primeira vez um pedido de faixa/intervalo. No entanto, a maioria dos CDNs atenderá às solicitações a partir do cache caso os dados estejam disponíveis. Por conseguinte, pode ser vantajoso se ter uma parte dos pedidos de cliente para um arquivo de segmento inteiro. Tais requisições podem ser posteriormente canceladas caso necessário.

[000136]Os pontos de comutação válidos podem ser pontos de busca, especificamente RAPs por exemplo, no fluxo alvo. São possíveis implementações diferentes, tais como estruturas fixas de GOP ou o alinhamento de RAPs através dos fluxos (com base no início dos mídia/meios de comunicação, ou com base nos GOPs).

[000137]Em uma modalidade, os segmentos e GOPs podem ser alinhados através de fluxos de taxas diferentes. Em tal modalidade, os GOPs pode ser de tamanho variável e podem conter múltiplos fragmentos, porém os fragmentos não estão alinhados entre os fluxos de taxas diferentes.

[000138]Em algumas modalidades, pode ser empregada a redundância de arquivos com vantagens. Em tais modalidades, é aplicado um código de apagamento é aplicado a cada fragmento para gerar versões redundantes dos dados. De preferência, a formatação de origem não é alterado devido ao uso de FEC, e os segmentos de reparação adicionais, por exemplo como uma representação dependente da representação original, contendo dados de reparo de FEC são gerados e disponibilizados como um passo adicional no sistema de ingestão. O cliente, que é capaz de reconstruir um fragmento usando somente dados de origem para tal fragmento, só pode solicitar dados de origem a partir dos servidores para o fragmento dentro do segmento. Caso os servidores não estejam disponíveis, ou caso a conexão para os servidores seja lenta, o que pode ser determinado antes ou depois do pedido de dados de origem, os dados de reparação adicionais podem ser requeridas para o fragmento a partir do segmento de reparação, o que diminui o tempo para entrega confiável do suficiente de dados para recuperar o fragmento, possivelmente através de decodificação FEC para usar uma combinação de dados de origem e dados de reparo para recuperar os dados de origem do fragmento. Além disso, podem ser solicitados dados de reparação adicionais para permitir a recuperação do fragmento caso um fragmento torne-se urgente, ou seja, o seu momento de reprodução torne-se iminente, o que aumenta o percentual de dados para tal fragmento em um link, mas que é mais eficiente do que encerrar as outras ligações no link para liberar amplitude de banda. Isto também pode reduzir o risco de falta de conteúdo devido à utilização de conexões paralelas.

[000139]O formato de fragmento pode ser um fluxo armazenado de pacotes de protocolo de rádio transporte em tempo real (RTP) com a sincronização de áudio/vídeo obtida através de protocolo de controle de transporte em tempo real RTCP.

[000140]O formato do segmento pode também ser um fluxo armazenada de pacotes MPEG-2 TS com sincronização de áudio/vídeo obtida através de temporização/timing interno MPEG-2 TS.

[000141]Usando Sinalização e/ou Criação de Blocos para Tornar o Streaming Mais Eficiente

[000142]Vários recursos ou características podem ou não ser usados em um sistema de streaming/fluxo contínuo por requisição de blocos para propiciar melhor desempenho. O desempenho pode estar relacionado à capacidade de reproduzir uma apresentação sem interrupções, à obtenção de dados de mídia dentro das restrições de amplitude de banda e/ou fazê-lo dentro dos recursos limitados de processadores em um sistema de cliente, servidor e/ou ingestão. Algumas destas características serão agora descritas. Indexação Dentro de Segmentos

[000143]Para formular requisições parciais GET para fragmentos de filmes, o cliente pode ser informado sobre o deslocamento/offset de byte e instante de início na decodificação ou momento de apresentação de todos os componentes de mídia contidos nos fragmentos dentro do arquivo ou segmento e também quais fragmentos que começam ou contenham pontos de acesso aleatório (e são portanto adequados para serem utilizados como pontos de comutação entre representações alternativas), em que tais informações são freqüentemente referidas como a indexação de segmentos ou mapa de segmentos. A hora/instante de início na decodificação ou no instante de apresentação pode ser expresso diretamente ou pode ser expresso como deltas/diferenças em relação a um tempo/instante de referência.

[000144]Tal tempo e informações de indexação de offset de bytes podem exigir pelo menos 8 bytes de dados por fragmento de filme. Como um exemplo, para um filme de duas horas contido em um único arquivo, com fragmentos de filme de 500 ms, isto seria um total de cerca de 112 kilobytes de dados. O download de todos esses dados quando se inicia uma apresentação pode resultar em um atraso adicional significativo de inicialização. No entanto, os dados de tempo e deslocamento de bytes podem ser codificados hierarquicamente, de modo que o cliente possa encontrar rapidamente um pequeno intervalo de tempo e dados de offset relevantes para o ponto da apresentação em que ele deseja iniciar. As informações podem também ser distribuídas dentro de um segmento de tal modo que algum refinamento do índice de segmento possa ser localizado intercalado com os dados multimídia.

[000145]Note-se que caso a representação seja segmentada no tempo em múltiplos segmentos, a utilização da presente codificação hierárquica pode não ser necessária, dado que o tempo completo e os dados de deslocamento para cada segmento podem já ser bastante pequenos. Como exemplo, caso os segmentos sejam de um minuto em lugar de duas horas no exemplo acima, as informações de tempo/indexação de bytes de offset constituem cerca de 1 kilobyte de dados, o que pode tipicamente caber dentro de um único pacote de TCP/IP.

[000146]Diferentes opções são possíveis para adicionar dados de tempo de fragmentos e offset a um arquivo 3GPP:

[000147]Primeiro, o box de acesso aleatório a fragmentos de filme (“MFRA”) pode ser usado para esta finalidade. O MFRA fornece uma tabela, que pode ajudar os leitores a encontrar pontos de acesso aleatório em um arquivo usando fragmentos do filme. Em apoio a esta função, o MFRA incidentalmente contém os offsets de bytes de caixas/boxes MFRA contendo pontos de acesso aleatório. O MFRA pode ser colocado na, ou perto da, extremidade do arquivo, mas isso não é necessariamente o caso. Ao pesquisar a partir do final do arquivo por um box de acesso aleatório a fragmentos de filme e usando as informações de tamanho no mesmo, pode-se localizar o início de um box de acesso aleatório a fragmentos de filme. No entanto, a colocação do MFRA no final para fluxo contínuo de HTTP requer tipicamente pelo menos 3 a 4 requisições HTTP para acessar os dados desejados: pelo menos um para solicitar o MFRA a partir da extremidade do arquivo, uma para obter o MFRA e, finalmente, uma para se obter o fragmento desejado no arquivo. Portanto, a colocação no início pode ser desejável, dado que o mfra pode ser baixado junto com os primeiros dados de mídia em uma única solicitação. Além disso, usando-se o MFRA para streaming HTTP pode ser ineficiente, uma vez que nenhuma das informações no MFRA é necessária, além do tempo e moof_offset e especificação dos deslocamentos/offsets em lugar de comprimentos poder exigir mais bits.

[000148]Em segundo lugar, pode ser usada a caixa/box de localização de item (iLOC). O "iLOC" fornece um diretório de recursos de metadados neste ou em outros arquivos, por localizar seu arquivo contendo seu deslocamento dentro desse arquivo e seu comprimento. Como exemplo, um sistema poderia integrar todos os recursos de metadados referenciados externamente em um arquivo, reajustando offsets/deslocamentos de arquivo e referências a arquivos em conformidade. No entanto, o "iLOC" destina-se a dar a localização de metadados, podendo por isso ser difícil a coexistência com metadados reais.

[000149]Por último, e talvez o mais adequado, é a especificação de um novo box/caixa, conhecido como Caixa de Índice de Tempo (TIDX), especificamente dedicado ao propósito de proporcionar os instantes/durações de fragmentos e offsets de bytes exatos de uma maneira eficiente. Isto será descrito em maiores detalhes na seção a seguir. Uma caixa alternativa com as mesmas funcionalidades pode ser a caixa de índices de segmento (SIDX). Aqui, salvo indicação em contrário, essas duas podem ser intercambiáveis, dados que as duas caixas propiciam a capacidade de fornecer os instantes ou durações exatos de fragmentos e deslocamentos de bytes de uma maneira eficiente. As diferenças entre a TIDX e a SIDX são fornecidas abaixo. Deve estar claro como permutar as caixas de TIDX e SIDX, dado que ambas implementam um índice de segmento. Indexação de Segmento

[000150]Um segmento possui um instante/tempo de início identificado e um número de bytes identificado. Múltiplos fragmentos podem ser concatenados em um único segmento e os clientes podem emitir pedidos que identificam o intervalo de bytes específico dentro do segmento que corresponde ao fragmento desejado, ou um subconjunto do fragmento. Como exemplo, quando o HTTP é utilizado como o protocolo de pedido, o cabeçalho/header de intervalo HTTP pode ser utilizado para tal finalidade. Esta abordagem requer que o cliente tenha acesso a um “índice de segmento” do segmento que especifica a posição dentro do segmento dos diferentes fragmentos. Tal índice de segmento pode ser fornecido como parte dos metadados. Tal abordagem apresenta o resultado de que muito menos arquivos precisam ser criados e gerenciados em comparação com aquela em que cada bloco é mantido em um arquivo separado. O gerenciamento da criação, transferência e armazenamento de um número muito grande de arquivos (o que poderia estender-se a vários milhares para uma apresentação de, digamos, 1 hora) pode ser complexo e sujeito a erros, desse modo reduzir o número de arquivos representa uma vantagem.

[000151]Caso o cliente conheça apenas o instante de início desejado de uma porção menor de um segmento, ele pode solicitar o arquivo inteiro e em seguida ler o arquivo de modo a determinar local do início da reprodução apropriado. Para melhorar a utilização da amplitude de banda, os segmentos podem incluir um arquivo de índice na forma de metadados, onde o arquivo de índice mapeia os intervalos de bytes de blocos individuais para os intervalos de tempo a que correspondem os blocos, o que é designado como indexação de segmentos ou mapeamento de segmentos. Tais metadados podem ser formatados como dados XML, ou podem ser binários, seguindo, por exemplo, a estrutura de átomo e caixa/box do formato de arquivo 3GPP. A indexação pode ser simples, em que os intervalos de tempo e de bytes de cada bloco são absolutos em relação ao início do arquivo, ou podem ser hierárquica, em que alguns blocos são agrupados em blocos de matriz/“pais” (e aqueles em blocos de avós e assim por diante) e o intervalo de tempo e de bytes para um dado bloco é expresso em relação ao tempo e/ou intervalo de bytes do bloco pai do bloco. Exemplo de Estrutura de Mapa de Indexação

[000152]Em uma modalidade, os dados fonte originais para uma representação de um fluxo de mídia podem estar contidos em um ou mais arquivos de mídia aqui chamado de "segmento de mídia", onde cada segmento de mídia contém os dados de mídia utilizados para a reprodução de um segmento de tempo contínuo dos mídia/meios de comunicação, por exemplo a 5 minutos da reprodução de mídia.

[000153]A Figura 6 ilustra um exemplo de uma estrutura de um segmento de mídia/meios de comunicação. No interior de cada segmento, seja no início ou a espalhadas por todo o segmento de origem/fonte, podem existir também informações de indexação, que compreendem um mapa de tempo/deslocamento ou offset de bytes de segmento. O mapa de tempo/offset de bytes do segmento em uma modalidade pode ser uma lista de pares de tempo/offset de bytes (T (0), B (0)), (T (1), B (1)), ..., (T (i ), B (i)), ..., (T (n), B (n)), em que T (i-1) representa um instante de início dentro do segmento para a reprodução do i° fragmento de mídia em relação ao tempo de início inicial dos mídia/meios de comunicação entre todos os segmentos de meios de comunicação, T (i) representa um tempo final para o i° fragmento (e, portanto, o tempo de início para o fragmento seguinte), e o deslocamento/offset de byte B(i-1) é o índice de byte correspondente do início dos dados dentro deste segmento de origem em que o i° fragmento de mídia começa em relação ao início do segmento de origem, e B(i) é o índice de byte correspondente à extremidade do i° fragmento (e, portanto, o índice do primeiro byte do fragmento seguinte). Caso o segmento contenha vários componentes de mídia, então T(i) e B(i) podem ser fornecidos para cada componente no segmento de uma maneira absoluta, ou podem ser expressados em relação a outro componente de mídia que serve como uma referência de componente de mídia/meios de comunicação.

[000154]Nesta modalidade, o número de fragmentos no segmento fonte/de origem é n, onde n pode variar de segmento para segmento.

[000155]Em outra modalidade, o offset de tempo no índice de segmento para cada fragmento pode ser determinado com o tempo/instante de início absoluto do primeiro fragmento e as durações de cada fragmento. Neste caso, o índice de segmento pode documentar o tempo de início do primeiro fragmento e da duração de todos os fragmentos que estão incluídos no segmento. O índice de segmento pode também documentar apenas um subconjunto dos fragmentos. Nesse caso, o índice de segmento documenta a duração de um subsegmento que é definido como um ou mais fragmentos consecutivos, terminando quer no final do segmento que o contém, ou no início do subsegmento seguinte.

[000156]Para cada fragmento, pode haver também um valor que indica se o fragmento começa ou não no, ou contém um, ponto de busca, isto é, em um ponto em que nenhum mídia após esse ponto depende quaisquer mídia anteriores a este ponto, e portanto os mídia/meios de comunicação do fragmento para a frente podem ser reproduzidos de forma independente de fragmentos anteriores. Pontos de busca/procura são, de um modo geral, os pontos nos meios de comunicação em que a reprodução pode iniciar independentemente de todos os mídia anteriores. A Figura 6 também ilustra um exemplo simples de possível segmento de indexação segmento para um segmento de origem. Neste exemplo, o valor de offset de tempo está em unidades de milissegundos e, portanto, o primeiro fragmento deste segmento de origem começa 20 segundos após o início dos mídia/meios de comunicação e o primeiro fragmento apresenta um tempo de reprodução de 485 milissegundos. O deslocamento/offset de byte do início do primeiro fragmento é 0, enquanto o deslocamento de byte do final do primeiro fragmento/início do segundo fragmento é 50.245, e, portanto, o primeiro fragmento possui um tamanho de 50.245 bytes. Caso o fragmento ou o subsegmento não comece com um ponto de acesso aleatório, porém o ponto de acesso aleatório esteja contido no fragmento ou subsegmento, então o tempo de decodificação ou diferença de tempo de apresentação entre o momento de início e do instante de RAP real pode ser calculado. Isto permite que em caso de mudança para este segmento de mídia, o cliente possa saber o tempo com precisão até que o interruptor de representação deve ser apresentado.

[000157]Adicionalmente, ou em lugar de, indexação simples ou hierárquica, poderiam ser usadas indexação encadeada tipo “daisy wheel” e/ou uma indexação híbrida.

[000158]Dado que as durações de amostras para diferentes trilhas/faixas podem ser diferentes (por exemplo, as amostras de vídeo podem ser exibidas por 33 ms, enquanto que uma amostra de áudio pode durar 80 ms), as diferentes trilhas de um fragmento de filme podem não começar e terminar precisamente no mesmo momento, ou seja, o áudio pode começar ligeiramente antes ou ligeiramente depois do vídeo, com o oposto sendo verdadeiro para o fragmento anterior, para compensar. Para evitar ambigüidade, as marcas de tempo/timestamps especificadas nos dados de offset de tempo e de bytes podem ser especificadas com relação a uma trilha/faixa em particular e esta pode ser a mesma trilha para cada representação. Usualmente, esta será a trilha de vídeo. Isso permite ao cliente identificar exatamente o próximo quadro de vídeo quando ele está mudando/comutando representações.

[000159]Devem ser tomadas precauções durante a apresentação para se manter uma estreita relação entre as escalas de tempo e o tempo de apresentação, para garantir uma reprodução suave, uniforme e a manutenção de sincronização de áudio e vídeo sincronização apesar do problema acima.

[000160]A Figura 7 ilustra alguns exemplos, tais como um índice simples 700 e um índice hierárquico 702.

[000161] São providos a seguir dois exemplos específicos de uma caixa/box que contém um mapa de segmento, um designado como caixa/box de índice de tempo (TIDX) e um referido como SIDX. A definição segue a estrutura de box/caixa de acordo com o formato de arquivo de mídia de base ISO. Outros esquemas para caixas deste tipo, para definir uma sintaxe semelhante e com a mesma semântica e funcionalidade são conhecidos pelos técnicos na área. Box de Índice de Tempo Definição Tipo de Caixa: “tidx” Container: Arquivo Obrigatória: Não Quantidade: Qualquer número zero ou um

[000162] O box de índice de tempo pode fornecer um conjunto de índices de tempo e offsets de bytes 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 targettype, que indica o tipo dos dados de referência. Por exemplo, uma caixa de índice de tempo com targettype “moof” fornece um índice para os fragmentos de mídia contidos no arquivo em termos de offsets/deslocamentos tanto tempo como de bytes. Uma caixa índice de tempo com targettype da caixa índice de tempo pode ser usada para montar um índice de tempo hierárquico, permitindo que os usuários do arquivo naveguem rapidamente para a parte necessária do índice.

[000163] O índice de segmento pode, por exemplo, conter a seguinte sintaxe: 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_access_flag; unsigned int (31) length; unsigned int (32) deltaT; } } Semântica: targettype: é o tipo dos dados da caixa referenciados por esta caixa de índice de tempo. Isso pode ser Fragmento de Header/Cabeçalho de Filme (“Moof”) ou Caixa de Índice de Tempo (“tidx”). time-reference_track_id: indica o caminho/trilha em relação ao qual os offsets de tempo neste índice são especificados. number_of_elements: o número de elementos indexados por esta caixa de índice de tempo. first_element_offset: O offset de bytes a partir do início do arquivo do primeiro elemento indexado. first_element_time: O tempo/instante de início do primeiro elemento indexado, utilizando a escala de tempo especificada na caixa de header de mídia da trilha/pista identificada por time_reference_track_id. random_access_flag: Um se o instante de início do elemento for um ponto de acesso aleatório. Caso contrário zero. length/comprimento: O comprimento do elemento indexado em bytes. deltaT: A diferença em termos da escala de tempo/timescale especificada na caixa de header de mídia da trilha identificada por time_reference_track_id entre o tempo de início deste elemento e a hora de início do elemento seguinte. Box/Caixa de Índice de Segmento

[000164] A caixa de índice de segmento (“sidx”) fornece um índice compacto dos fragmentos de filmes e outras caixas de índices de segmento em um segmento. Existem duas estruturas de loop/enlace na caixa de índice de segmento . O primeiro loop documenta a primeira amostra do subsegmento, isto é, a amostra no primeiro fragmento de filme referenciado pelo segundo enlace. O segundo enlace fornece um índice do subsegmento. O container para a caixa “sidx” é diretamente o arquivo ou segmento. Sintaxe aligned(8) class SegmentIndexBox extends FullBox ('sidx', version 0) { unsigned int (32) reference_track_ID; unsigned int (16) track_count; unsigned int (16) reference_count; for (i = 1; i <= track_count; i++) { unsigned int (32) track_ID; if (versão == 0) { unsigned int (32) decoding_time; } Else { unsigned int (64) decoding_time; } } for (i = 1; i <= reference_count; i++) { bit (1) reference_type; unsigned int (31) reference_offset; unsigned int subsegment_duration (32); bit (1) contains_RAP; unsigned int (31) RAP_delta_time; } } Semântica: reference_track_ID fornece o track_ID para a faixa ou trilha de referência. track_count: o número de faixas indexadas no enlace seguinte (1 ou superior); reference_count: o número de elementos indexados por segundo enlace (1 ou superior); track_ID: a ID de uma faixa para a qual um fragmento de faixa está incluído no primeiro fragmento de filme identificado por este índice; exatamente uma track_ID neste loop é igual à reference_track_ID; decoding_time: o tempo de decodificação para a primeira amostra na faixa identificada por track_ID no fragmento de filme referenciado pelo primeiro item no segundo enlace, expressado na escala de tempo da trilha (conforme documentado no campo de escala de tempo do cabeçalho/header de mídia box da trilha); reference_type: quando definido como 0, indica que a referência é para um box de fragmento de filme (moof), quando definido como 1, indica que a referência é para um índice de caixa/box de segmento (sidx); reference_offset: a distância em bytes do primeiro byte na seqüência da caixa de índice de segmento até o primeiro byte da caixa referenciada; subsegment_duration: quando a referência é para caixa de índice de segmento, este campo porta a soma dos campos subsegment_duration no segundo enlace da referida caixa, e quando a referência é para um fragmento de filme, este campo transporta a soma das durações de amostras das amostras na trilha de referência, no fragmento de filme indicado e fragmentos de filme subseqüentes até o primeiro fragmento de filme documentado pela próxima entrada no enlace, ou o fim do subsegmento, o que ocorrer primeiro; a duração é expressada na escala de tempo da trilha (tal como documentado no campo timescale do box de header de mídia da trilha); contains_RAP: quando a referência é para um fragmento de filme, então este bit pode ser 1 caso o fragmento de trilha dentro desse fragmento de filme para a trilha com track_ID igual a reference_track_ID contém pelo menos um ponto de acesso aleatório; caso contrário esse bit é definido como 0; quando a referência é para um índice de segmento, então este bit é definido como 1 somente se qualquer uma das referências em que o índice do segmento tem esse bit ajustado para 1 e 0 em caso contrário; RAP_delta_time: se contains_RAP for 1, proporciona o tempo de apresentação (composição) de um ponto de acesso aleatório (RAP); reservado com o valor 0 caso contains_RAP for 0. O tempo é expressado como a diferença entre o tempo de decodificação da primeira amostra do subsegmento documentado por esta entrada e o instante de apresentação (composição) do ponto de acesso aleatório, na faixa com track_ID igual a reference_track_ID.

Diferenças entre TIDX e SIDX

[000165] O SIDX e o SIDX fornecem a mesma funcionalidade no que diz respeito à indexação. O primeiro enlace do SIDX fornece adicionalmente o timing global para o primeiro fragmento de filme, mas o timing global pode também estar contido no próprio fragmento de filme, seja de forma absoluta ou relativa em relação à trilha de referência.

[000166] O segundo enlace do SIDX implementa a funcionalidade do TIDX. Especificamente, o SIDX permite dispor de uma mistura de alvos para a referência para cada índice referido por reference_type, enquanto o TIDX faz referência apenas ao TIDX ou apenas moof. O number_of_elements em TIDX corresponde à referemce_count em SIDX, o time_reference_track_id no TIDX corresponde a reference_track_ID em SIDX, o tfirst_element_offset em TIDX corresponde a reference_offset na primeira entrada do segundo enlace, first_element_time em TIDX corresponde a decoding_time de reference_track no primeiro enlace, random_access_flag em TIDX corresponde a contains_RAP no SIDX com a liberdade adicional de que no SIDX o RAP pode não ser necessariamente colocado no início do fragmento e, portanto, exige o RAP_delta_time, o comprimento/length em TIDX corresponde a reference_offset em SIDX e, finalmente, deltaT em TIDX corresponde a subsegment_duration no SIDX. Por conseguinte, as funcionalidades das duas caixas são equivalentes.

Dimensionamento Variável de Blocos e Blocos Sub-GOP

[000167]Para mídia/meios de comunicação de vídeo, pode ser importante a relação entre a estrutura de codificação de vídeo e a estrutura de bloco para requisições. Como exemplo, se cada bloco começa com um ponto de busca, tal como um ponto de acesso aleatório ("RAP"), e cada bloco representa um período de tempo igual de vídeo, então o posicionamento de pelo menos alguns ponto de busca na mídia de vídeo é fixo e pontos de busca irão ocorrer em intervalos regulares dentro da codificação de vídeo. Como é bem conhecido pelos técnicos na área de codificação de vídeo, a eficiência de compressão pode ser melhorada caso os pontos de busca são posicionados de acordo com as relações entre os quadros de vídeo, em particular se eles estão colocados em quadros que têm pouco em comum com quadros anteriores. Esta exigência de que os blocos representem quantidades iguais de tempo, portanto, coloca uma restrição à codificação de vídeo, tal como a compressão que pode ser menos que a ideal ou sub-ótima.

[000168]É desejável permitir que a posição de pontos de busca dentro de uma apresentação de vídeo seja escolhida pelo sistema de codificação de vídeo, em lugar de exigir pontos de procura em posições fixas. Permitir que o sistema de codificação de vídeo escolha os pontos de busca resulta em melhor compressão de vídeo e, portanto, uma maior qualidade de mídia de vídeo pode ser fornecida com uma determinada amplitude de banda, resultando em uma experiência de usuário aprimorada. Os sistemas atuais de requisição em blocos de streaming podem exigir que todos os blocos possuam a mesma duração (em termos de tempo de vídeo), e que cada bloco comece com um ponto de busca e isto é, portanto, uma desvantagem dos sistemas existentes.

[000169] Será agora descrito um novo sistema de streaming por requisição de blocos que proporciona vantagens em relação ao que foi acima descrito. Em uma modalidade, o processo de codificação de vídeo de uma primeira versão do componente de vídeo pode ser configurado para selecionar as posições de pontos de busca de modo a otimizar a eficiência de compressão, mas com um requisito de que exista um máximo na a duração entre pontos de busca. Este último requisito restringe a escolha de pontos de busca pelo processo de codificação e, assim, reduz a eficiência de compressão. No entanto, a redução na eficiência de compressão é pequena comparada com aquela imposta caso posições fixas regulares sejam necessárias para os pontos de procura, contanto que o máximo da duração entre pontos de busca não seja muito pequena (por exemplo, maior do que cerca de um segundo). Além disso, se o máximo da duração entre pontos de busca for de alguns segundos, então a redução na eficiência de compressão em relação ao posicionamento completamente livre de pontos de busca é geralmente muito pequena.

[000170]Em muitas modalidades, incluindo a presente, pode ocorrer que alguns RAPs não são pontos de busca, isto é, pode existir um quadro que é um RAP que se encontra entre dois pontos de busca consecutivos que não é escolhido para ser um ponto de busca, por exemplo porque o RAP está demasiado próximo no tempo aos pontos de busca vizinhos, ou porque a quantidade de dados multimídia entre o ponto de busca antes ou após o RAP e o RAP é muito pequena.

[000171]A posição de pontos de busca dentro de todas as outras versões da apresentação de mídia pode ser restringida a ser a mesma que a dos pontos de busca em uma versão (por exemplo, a de taxa de dados mais elevada) primeiro. Isto reduz a eficiência de compressão para estas outras versões em comparação com o permitir a escolha livre ao codificador dos pontos de busca.

[000172]A utilização de pontos de procura tipicamente requeria que um quadro fosse independentemente decodificável, o que geralmente resulta em uma eficiência de compressão baixa para tal quadro. Os quadros que não necessitam ser independentemente decodificáveis podem ser codificados com referência a dados em outros quadros, o que geralmente aumenta a eficiência de compressão para tais quadros em um grau que é dependente da quantidade de homogeneidade entre o quadro a ser codificado e os quadros de referência. Uma escolha eficiente do posicionamento de pontos de busca preferencialmente escolhe como um quadro de ponto de busca um quadro que tenha pouco em comum com quadros anteriores e desse modo minimiza a perda de eficiência de compressão pela codificação da estrutura de uma forma que seja independente decodificável.

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

[000174]A estrutura ponto de busca é de preferência utilizada para determinar a estrutura de bloco. De preferência, cada ponto de busca determina o início de um bloco, podendo haver um ou mais blocos que englobam os dados entre dois pontos de busca consecutivos. Dado que a duração entre pontos de busca não é fixa para codificação com boa compressão, nem todos os blocos precisam ter a duração de reprodução igual. Em algumas modalidades, os blocos estão alinhados entre as versões do conteúdo - isto é, se houver um bloco abrangendo um grupo específico de quadros em uma versão do conteúdo, então há um bloco que abrange o mesmo grupo de quadros em uma outra versão do conteúdo. Os blocos de uma determinada versão do conteúdo não se sobrepõem e cada quadro/frame do conteúdo está contido exatamente no interior de um bloco de cada versão.

[000175]Uma característica que permite a utilização eficiente de durações variáveis entre pontos de busca e, portanto, GOPs com duração variável, é a indexação de segmentos ou mapa de segmentos que podem ser incluídos em um segmento ou fornecidos por outros meios para um cliente, isto é, metadados associados com este segmento nesta representação que possam ser fornecidos compreendendo a hora de início e a duração de cada bloco da apresentação. O cliente pode usar esses dados de indexação de segmento na determinação do bloco em que iniciar a apresentação quando o usuário solicitar que a apresentação comece em um determinado ponto que está dentro de um segmento. Caso tais metadados não sejam fornecidos, a apresentação só pode começar no início do conteúdo, ou em um ponto aleatório ou próximo ao ponto desejado (por exemplo, por escolha do bloco de partida por divisão do ponto de partida requerido (em tempo) pela duração média do bloco para encontrar o índice do bloco de partida).

[000176]Em uma modalidade, cada bloco pode ser fornecido como um arquivo separado. Em outra modalidade, vários blocos consecutivos podem ser agregadas em um único arquivo para formar um segmento. Nesta segunda modalidade, metadados para cada versão podem ser proporcionados compreendendo a hora de início e duração de cada bloco e o deslocamento/shift de bytes dentro do arquivo em que o bloco começa. Estes metadados podem ser fornecidos em resposta a uma solicitação de protocolo inicial, isto é, disponíveis separadamente a partir do segmento ou arquivo, ou podem estar contidos dentro do mesmo arquivo ou segmento que os próprios blocos, por exemplo no início do arquivo. Como ficará claro para os técnicos na área, tais metadados podem ser codificados numa forma comprimida, tais como codificação gzip ou delta ou em forma binária, de modo a reduzir os recursos de rede necessárias para transportar os metadados para o cliente.

[000177]A Figura 6 mostra um exemplo de indexação de segmento em que os blocos são de tamanho variável e em que o âmbito de blocos é um GOP parcial, ou seja, uma quantidade parcial dos dados multimídia entre um RAP e o RAP seguinte. Neste exemplo, os pontos de busca estão indicados pelo indicador de RAP, em que um valor indicador RAP de 1 indica que o bloco começa com, ou contém, um RAP, ou ponto de busca, e em que um indicador RAP de 0 indica que o bloco não contém RAP ou ponto de busca. Neste exemplo, os primeiros três blocos, isto é, os bytes de 0 a 157.033, compreendem o primeiro GOP, que tem uma duração de apresentação de 1,623 segundos, com um tempo de apresentação em execução a partir de 20 segundos para o conteúdo a 21,623 segundos. Neste exemplo, o primeiro dos três primeiros blocos compreende 0,485 segundo de tempo de apresentação e compreende os primeiros 50.245 bytes dos dados multimídia no segmento. Neste exemplo, os blocos 4, 5 e 6 compreendem o segundo GOP, os blocos 7 e 8 compreendem o terceiro GOP e os blocos 9, 10 e 11 compreendem o quarto GOP. Note-se que pode haver outros RAPs nos dados multimídia que não são designados como pontos de busca e não são, portanto, assinalados como RAPs no mapa de segmento.

[000178]Fazendo novamente referência à Figura 6, caso o cliente ou receptor queira acessar o conteúdo de partida no offset de tempo de aproximadamente 22 segundos na apresentação de mídia, então o cliente poderia inicialmente recorrer a outras informações, como o MPD descrito em maiores detalhes mais adiante, para primeiro determinar que os dados de mídia relevantes estão dentro deste segmento. O cliente pode baixar a primeira porção do segmento para se obter a indexação do segmento, que neste caso é de apenas alguns bytes, utilizando por exemplo uma requisição HTTP de intervalo de byte. Usando a indexação do segmento, o cliente pode determinar que o primeiro bloco que deve baixar é o primeiro bloco com um offset de tempo que é no máximo de 22 segundos e que começa com um RAP, isto é, é um ponto de busca. Neste exemplo, embora o bloco 5 apresente um offset de tempo que é menor do que 22 segundos, isto é, o seu tempo de deslocamento é 21,965 segundos, a indexação de segmento indica que o bloco 5 não começa com uma RAP e, assim, em lugar disso, com base no segmento de indexação, o cliente seleciona baixar o bloco 4, já que seu horário de início é no máximo 22 segundos, ou seja, o seu tempo de deslocamento é 21,623 segundos, e ele começa com uma RAP. Assim, com base na indexação de segmento, o cliente vai fazer uma solicitação HTTP de intervalo gama a partir do offset de byte 157.034.

[000179]Caso as indexações de segmento não estivessem disponíveis, então o cliente poderia ter que baixar todos os 157.034 bytes de dados anteriores antes de baixar esses dados, levando a um tempo de inicialização muito mais longo, ou maior tempo de zapping de canais, e ao desperdício de download de dados que não são úteis. Alternativamente, caso as indexações de segmentos não estiverem disponíveis, o cliente pode aproximar onde os dados desejados se iniciam dentro do segmento, mas a aproximação pode ser ruim e pode perder o momento apropriado e então exigir o retrocesso, o que aumenta o retardo de partida.

[000180]De um modo geral, cada bloco inclui uma porção dos dados multimídia que, em conjunto com os blocos anteriores, podem ser reproduzidos por um leitor de media. Assim, a estrutura de blocos e a sinalização da estrutura de indexação de segmentos de blocos para o cliente, ou contida dentro do segmento ou fornecida ao cliente através de outros meios, pode melhorar significativamente a capacidade do cliente para fornecer rápido zapping de canal e de reprodução sem interrupções face às variações e interrupções de rede. O suporte de blocos de duração variável e de blocos que englobam apenas partes de um GOP, tal como habilitado pela indexação de segmentos, pode melhorar significativamente a experiência de streaming. Como exemplo, fazendo novamente referência à Figura 6 e ao exemplo descrito acima, onde o cliente quer começar a reprodução em aproximadamente 22 segundos de apresentação, o cliente pode solicitar, através de uma ou mais requisições, os dados dentro do bloco 4 e, em seguida, alimentar estes ao reprodutor de mídia assim que estiverem disponíveis para iniciar a reprodução. Dessa forma, neste exemplo, a reprodução começa logo que os 42.011 bytes do bloco 4 sejam recebidos no cliente, permitindo assim um rápido zapping de canal. Caso, ao contrário, o cliente necessite requisitar todo o GOP antes que a reprodução se inicie, o tempo de zapping de canal seria mais longo, dados que são 144.211 bytes de dados.

[000181]Em outras modalidades, RAPs ou pontos de busca também podem ocorrer no meio de um bloco, podendo haver dados no segmento de indexação que indicam onde que um RAP ou ponto de busca se encontram dentro do bloco ou fragmento. Em outras modalidades, o offset de tempo pode ser o tempo de decodificação do primeiro quadro dentro do bloco, em lugar do tempo de apresentação do primeiro quadro dentro do bloco.

[000182]As Figuras 8(a) e (b) ilustram um exemplo de dimensionamento variável de bloco em uma estrutura de pontos de busca alinhados através de uma pluralidade de versões ou representações. A Figura 8(a) ilustra o dimensionamento variável de bloco em uma estrutura de pontos de busca alinhados ao longo de uma pluralidade de versões de um fluxo de mídia/meios de comunicação, enquanto que a Figura 8(b) ilustra o dimensionamento variável de bloco com pontos de busca não alinhados em uma pluralidade de versões de um fluxo de mídia.

[000183]O tempo é mostrado na parte superior, em segundos, e os blocos e pontos de busca dos dois segmentos para as duas representações são mostrados da esquerda para a direita em termos da sua temporização/timing com respeito a tal linha de tempo e portanto o comprimento de cada bloco mostrado é proporcional ao seu tempo de reprodução e não proporcional ao número de bytes no bloco. Neste exemplo, a indexação de segmento para ambos os segmentos das duas representações teria os offsets de tempo iguais para os pontos de busca, mas uma quantidade potencialmente diferente de blocos ou fragmentos entre pontos de busca e os desvios de byte diferentes para os blocos devido às quantidades diferentes de dados de mídia em cada bloco. Neste exemplo, caso o cliente deseje mudar da representação 1 para a representação 2 no tempo de apresentação de aproximadamente 23 segundos, o cliente pode solicitar até o bloco 1.2 no segmento de representação 1 e começar a requisitar o segmento para a representação 2 começando no bloco 2.2 e assim a comutação ocorreria na apresentação coincidindo com ponto de busca 1.2 na representação 1, o qual ocorre ao mesmo tempo que o ponto de busca 2.3 na representação 2.

[000184]Como deve estar claro pelo que foi exposto, o sistema de streaming por solicitação de blocos descrito não restringe a codificação de vídeo a colocar pontos de busca em posições específicas dentro do conteúdo e isso atenua um dos problemas dos sistemas existentes.

[000185]Nas modalidades acima descritas, o sistema é organizado de modo a que os pontos de busca das várias representações do mesmo conteúdo de apresentação ficam alinhados. No entanto, em muitos casos, é preferível dispensar tal requisito de alinhamento. Como exemplo, algumas vezes as ferramentas de codificação são usadas para gerar as representações que não têm as capacidades para gerar representações alinhadas com pontos de procura. Como outro exemplo, a apresentação de conteúdo pode ser codificada em diferentes representações de forma independente, sem nenhum alinhamento dos pontos de busca entre as diferentes representações. Como outro exemplo, uma representação pode conter mais pontos de busca, pois apresenta taxas mais baixas e mais comumente precisa ser comutada ou que contém pontos de busca para suportar modos com outros recursos tais como avançar ou retroceder rapidamente ou com busca rápida. Dessa forma, é desejável a provisão de métodos que tornam um sistema de fluxo em streaming por requisição de blocos capaz de lidar de forma eficiente e sem interrupções com pontos de procura não alinhados através das várias representações para uma apresentação de conteúdo.

[000186]Na presente modalidade, as posições dos pontos de busca através das representações podem não se alinhar. Os blocos são construídos de tal modo que um novo bloco começa em cada ponto de busca e, portanto, pode não haver alinhamento entre os blocos de diferentes versões da apresentação. Um exemplo de tal estrutura de pontos de busca não alinhados entre diferentes representações é apresentado na Figura 8(b). O tempo é mostrado na parte superior, em segundos, e os blocos e pontos de busca dos dois segmentos para as duas representações são mostrados da esquerda para a direita em termos da sua temporização no que diz respeito a esta linha de tempo e, portanto, o comprimento de cada bloco mostrado é proporcional ao seu tempo de reprodução e não proporcional ao número de bytes no bloco. Neste exemplo, a indexação de segmentos para ambos os segmentos das duas representações teria offsets de tempo potencialmente diferentes para os pontos de busca, e também números de blocos ou fragmentos potencialmente diferentes entre pontos de busca e offsets de bytes diferentes para os blocos, devido às diferentes quantidades de dados de mídia em cada bloco. Neste exemplo, se o cliente deseja comutar da representação 1 para a representação 2 no tempo de apresentação de cerca de 25 segundos, o cliente pode solicitar até o bloco 1.3 no segmento de representação 1, e começar a requisitar o segmento para a representação 2 começando no bloco 2.3 e, assim, a comutação ocorreria 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 portanto alguns dos mídia/meios de comunicação para o bloco 1.2 não seriam reproduzidos (apesar de os dados multimídia para os quadros do bloco 1.3 que não são reproduzidos podem ter que ser carregados para o buffer do receptor para decodificação de outros quadros do bloco 1.3 que são reproduzidos).

[000187]Em tal modalidade, a operação do seletor de blocos 123 pode ser modificada de tal modo que sempre que for necessário selecionar um bloco a partir de uma representação que é diferente da versão previamente selecionada, é escolhido o último bloco cujo primeiro quadro não é posterior ao quadro subseqüente ao último quadro do último bloco selecionado.

[000188]Esta última modalidade descrita pode eliminar a necessidade de restringir as posições de pontos de busca dentro de outras versões que não a primeira versão e portanto aumentar a eficiência de compressão para essas versões, resultando em uma apresentação de qualidade superior para uma determinada amplitude de banda disponível, levando a uma experiência de usuário aprimorada. Uma outra consideração é a de que as ferramentas de codificação de vídeo, que desempenham a função de alinhamento de pontos 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 desta última modalidade é a de que as ferramentas de codificação de vídeo atualmente disponíveis podem ser utilizados. Outra vantagem é a de que a codificação de diferentes versões do conteúdo pode ocorrer em paralelo, sem qualquer necessidade de coordenação entre os processos de codificação para as diferentes versões. Outra vantagem é a de que versões adicionais do conteúdo podem ser codificadas e adicionadas à apresentação em um momento posterior, sem se ter que prover as ferramentas de codificação com as listas de posições específicas de pontos de busca.

[000189]De um modo geral, quando as imagens são codificadas como grupos de imagens (GOPs), a primeira foto/imagem da seqüência pode ser um ponto de busca, mas tal não precisa ser sempre o caso.

Particionamento Ideal de Blocos

[000190]Uma preocupação em um sistema de streaming com requisição de blocos consiste da interação entre a estrutura dos mídia/meios de comunicação codificados, por exemplo, uma mídia de vídeo, e a estrutura de blocos usada para requisições de blocos. Como saberão os técnicos na área de codificação de vídeo, muitas vezes ocorre o caso em que o número de bits necessários para a representação codificada de cada quadro de vídeo varia, por vezes substancialmente, de quadro para quadro. Como resultado, a relação entre a quantidade de dados recebidos e a duração dos meios de comunicação codificados por tais dados pode não ser simples ou direta. Além disso, a divisão de dados de mídia em blocos dentro de um sistema de streaming por requisição de blocos acrescenta uma nova dimensão de complexidade. Em particular, em alguns sistemas, os dados de mídia de um bloco não podem ser reproduzidos até que todo o bloco tenha sido recebido; por exemplo o arranjo dos dados de mídia dentro de um bloco ou as dependências entre as amostras de mídia dentro de um bloco do uso de códigos de apagamento pode resultar em tal propriedade. Como resultado de tais interações complexas entre o tamanho do bloco e a duração do bloco e da eventual necessidade de receber um bloco inteiro antes de iniciar a reprodução é comum que os sistemas de clientes adotem uma abordagem conservadora em que os dados de mídia são acumulados em buffer antes que se inicia a reprodução. Tal acumulação em buffer resulta em um longo tempo de zapping de canal e portanto em uma experiência pobre para o usuário.

[000191]Pakzad descreve “métodos para particionamento de blocos" que são métodos novos e eficientes para determinar como particionar um fluxo de dados em blocos contíguos com base na estrutura subjacente do fluxo de dados e descreve ainda várias vantagens destes métodos no contexto de um sistema de fluxo contínuo ou streaming. Será agora descrita outra modalidade da invenção para a aplicação dos métodos de partição de Pakzad a um sistema de streaming por requisição de blocos. Este método pode compreender arranjar os dados de mídia de modo a serem apresentados na ordem aproximada do tempo de apresentação, de tal modo que o tempo de reprodução de qualquer dado elemento de dados de mídia (por exemplo, um quadro de vídeo ou uma amostra de áudio) difere daquela de qualquer elemento de dados de mídia adjacente por menos que um limite provido. Os dados de mídia assim ordenados podem ser considerados um fluxo de dados na linguagem de Pakzad e quaisquer dos métodos de Pakzad aplicados a tal fluxo de dados identificam limites de blocos com o fluxo de dados. Os dados entre qualquer par de limites de blocos adjacentes é considerado um “bloco” na linguagem de tal descrição e os métodos desta divulgação são aplicados para prover a apresentação dos dados de mídia dentro de um sistema de streaming por requisição de blocos. Como ficará claro para os técnicos na área através da leitura da presente descrição, as várias vantagens dos métodos divulgados por Pakzad podem então ser realizadas no contexto de um sistema de streaming ou fluxo contínuo por requisição de blocos.

[000192]Tal como descrito em Pakzad, a determinação da estrutura do bloco de um segmento, incluindo os blocos que englobam GOPs parciais ou porções de mais do que em GOP, pode ter impacto na capacidade do cliente para permitir o tempo rápido de zapping de canal. Em Pakzad, são providos métodos que, dado um tempo meta de inicialização, proporcionariam uma estrutura de bloco e uma taxa de download meta que iriam garantir que se o cliente iniciou o download da representação em qualquer ponto de busca e começou a reprodução após o tempo de inicialização meta ter decorrido, a reprodução continuaria sem interrupções enquanto em cada ponto no tempo a quantidade de dados que o cliente tenha baixado seja pelo menos a taxa de download meta, dado que isto propicia ao cliente um meio para determinar quando deve iniciar a reprodução da representação no tempo mais cedo possível, permitindo ao cliente continuar a reproduzir a representação contanto que o download atenda à condição acima descrita. Dessa forma, o método descrito posteriormente provê um meio para incluir o tempo de partida meta e a taxa de download meta na descrição de apresentação de mídia, de forma que ela possa ser usada para os propósitos acima descritos.

Modelo de Dados de Apresentação de Mídia

[000193]A Figura 5 ilustra possíveis estruturas do armazenamento de conteúdo mostrado na Figura 1, incluindo segmentos e arquivos de descrição de apresentação de mídia (MPD) e uma repartição dos segmentos, timing e outras estruturas dentro de um arquivo MPD. Serão agora descritos detalhes de possíveis implementações de estruturas ou arquivos MPD. Em vários exemplos, o MPD está descrito como um arquivo, mas podem também ser usadas estruturas que não de arquivos.

[000194]Tal como está ali ilustrado, o armazenamento de conteúdo 110 mantém uma pluralidade de segmentos de origem 510, MPDs 500 e segmentos de reparo 512. Um MPD pode compreender registros de períodos 501, os quais por sua vez podem compreender registros de representação 502 que contêm informações de segmentos 503, tais como referências a segmentos de inicialização 504 e segmentos de mídia 505.

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

[000196]Nos métodos aqui descritos é provida uma “descrição de apresentação de mídia” que compreende informações sobre as representações da apresentação dos mídia que estão disponíveis para o cliente. As representações podem ser alternativas no sentido de que o cliente seleciona uma dentre as diferentes alternativas, ou elas podem ser complementares no sentido de que o cliente seleciona várias das representações, cada uma possivelmente também a partir de um conjunto de alternativas, e apresenta- as em conjunto. As representações podem vantajosamente ser designadas para grupos, com o cliente programado ou configurado para compreender que, para as representações em um grupo, elas são, cada uma alternativas para as outras, enquanto as representações de diferentes grupos são tais que mais do que uma representação deve ser apresentada em conjunto. Em outras palavras, se houver mais do que uma representação de um grupo, o cliente escolhe uma representação desse grupo, uma representação dentre o grupo seguinte e assim por diante, para formar uma apresentação.

[000197]As informações descrevendo representações podem vantajosamente incluir detalhes dos CODECs de midia aplicados, incluindo perfis e níveis dos CODECs que são necessários para decodificar a representação, as taxas de quadros de vídeo, a resolução de vídeo e as taxas de dados. O cliente que recebe a descrição de apresentação de mídia pode usar tais informações para determinar de antemão se uma representação é adequada para decodificação ou apresentação. Isto representa uma vantagem, pois se as informação diferenciais estivessem contidas apenas nos dados binários da representação seria necessário solicitar os dados binários de todas as representações e analisar e extrair as informações relevantes a fim de descobrir informações sobre a sua adequação. Estes pedidos múltiplos e a análise por extração do anexo dos dados pode levar algum tempo o que resultaria em um longo tempo de inicialização/partida e, portanto, a uma má experiência para o usuário.

[000198]Adicionalmente, a descrição de apresentação de mídia pode incluir informações que restringem as requisições de clientes com base na hora do dia. Como exemplo, para um serviço “ao vivo” o cliente pode ser limitado a solicitar partes da apresentação que estejam próximas do “instante de broadcast atual”. Isto representa uma vantagem dado que, para transmissão ao vivo, pode ser desejável purgar os dados da infra-estrutura servidora de conteúdo que tenha sido transmitido há mais do que um limite fornecido antes do instante de broadcast atual. Isto pode ser desejável para a reutilização de recursos de armazenamento no interior da infra- estrutura de serviço. Isto também pode ser desejável, dependendo do tipo de serviço oferecido; por exemplo, em alguns casos uma apresentação pode ser disponibilizada apenas ao vivo devido a um certo modelo de assinatura determinado para dispositivos cliente receptores, enquanto que outras apresentações de mídia poderão ser disponibilizadas ao vivo e “on demand”/a pedido, e outras apresentações podem ser disponibilizados apenas ao vivo para uma primeira classe de dispositivos clientes, apenas sob demanda para uma segunda classe de dispositivos de cliente, 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 (a seguir) permite que o cliente seja informado de sobre tais políticas para que o cliente possa evitar fazer requisições e ajustar as ofertas para o usuário, para dados que podem não estar disponíveis na infra- estrutura de serviço. Como uma alternativa, por exemplo, o cliente pode apresentar uma notificação para o usuário de que tais dados não estão disponíveis.

[000199]Em outra modalidade da invenção, os segmentos de mídia podem estar de acordo com o formato de arquivo ISO de base de mídia descrito na norma ISO/IEC 14496-12 ou especificações derivadas (tal como o formato de arquivo 3GP descrito na Especificação Técnica 3GPP 26.244). O uso da seção 3GPP File Format (acima) descreve aprimoramentos novos no formato de arquivo ISO base de mídia que permitem o uso eficiente das estruturas de dados do formato de arquivo dentro de um sistema de streaming por solicitação de blocos. Conforme descrito nesta referência, as informações podem ser fornecidas dentro do arquivo o que permite rápido e eficiente mapeamento entre os segmentos de tempo da apresentação de mídia e os intervalos de bytes dentro do arquivo. Os dados de mídia em si podem ser estruturados de acordo com a estrutura de Fragmento de Filme definido na ISO/IEC14496-12. Tais informações fornecendo deslocamentos/offsets de tempo e bytes podem ser estruturadas hierarquicamente, ou como um único bloco de informações. Tais informações podem ser fornecidas no início do arquivo. O fornecimento de tais informações usando uma codificação eficiente, conforme descrito na seção de Uso de Formato de arquivo 3GPP resulta no cliente ser capaz de recuperar essas informações rapidamente, usando por exemplo uma requisição parcial do tipo HTTP GET, no caso em que o protocolo de download de arquivos usado pelo sistema de streaming por solicitação de blocos é o HTTP, o que resulta em um curto tempo de partida, procura, ou comutação de fluxo e, portanto, uma experiência de usuário aprimorada.

[000200]As representações em uma apresentação de mídia são sincronizadas em um cronograma/timeline global para garantir comutação perfeita e sem interrupções em representações, sendo tipicamente alternativas, e para assegurar uma apresentação sincronizada de duas ou mais representações. Portanto, o timing de amostras de mídia contidos nas representações dentro de uma apresentação em streaming HTTP adaptável pode estar relacionado a uma linha de tempo contínua global através de múltiplos segmentos.

[000201]Um bloco de mídia codificada contendo mídia de vários tipos, por exemplo áudio e vídeo, pode ter tempos diferentes de final de apresentação para os diferentes tipos de mídia. Em um sistema de streaming por solicitação de blocos, tais blocos de transmissão poderão ser reproduzidos consecutivamente de modo a que cada tipo de mídia seja reproduzido continuamente e, portanto, amostras de mídia de um tipo de um bloco podem ser reproduzidas antes de amostras de mídia de um outro tipo do bloco anterior, o que é aqui referido como “emenda contínua de blocos”. Como alternativa, tais blocos de mídia podem ser reproduzidos de modo tal que a primeira amostra de qualquer tipo de bloco é reproduzida depois da última amostra de qualquer tipo do bloco anterior, o que é aqui referido como “emenda descontínua de blocos”. A emenda contínua de blocos pode ser apropriada quando ambos os blocos contêm mídia provenientes do mesmo item de conteúdo e da mesma representação, codificados em seqüência, ou em outros casos. Tipicamente, dentro de uma representação a emenda contínua de blocos pode ser aplicada quando são emendados dois blocos. Isto é vantajoso pois uma codificação existente pode ser aplicada e a segmentação pode ser efetuada sem a necessidade de alinhar as trilhas de mídia nos limites de bloco. Isto está ilustrado na Figura 10, em que o fluxo/stream de vídeo 1000 inclui o bloco e outros blocos, com RAPs tais como o RAP 1204.

Descrição de Apresentação de Mídia

[000202]Uma apresentação de mídia pode ser considerada como uma coleção estruturada de arquivos em um servidor de streaming HTTP. O cliente de HTTP streaming pode baixar informações suficientes para apresentar o serviço de streaming para o usuário. Representações alternativas podem ser compostas por um ou mais arquivos 3GP ou partes de arquivos 3GP em conformidade com o formato de arquivo 3GPP ou pelo menos em conformidade com um conjunto bem definido de estruturas de dados que podem ser facilmente convertidas a partir de, ou para, um arquivo 3GP.

[000203]Uma apresentação de mídia pode ser descrita por uma descrição de apresentação de mídia. A descrição de apresentação de mídia (MPD) pode conter metadados que o cliente pode usar para construir solicitações/requisições de arquivos apropriadas, por exemplo solicitações HTTP GET, para acessar os dados em tempo oportuno e para fornecer o serviço de streaming para o usuário. A descrição de apresentação de mídia pode fornecer informações suficientes para o cliente de streaming HTTP selecionar os arquivos 3GPP apropriados e partes de arquivos. As unidades que são sinalizadas para o cliente como estando acessíveis são designadas como segmentos.

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

[000205]Um elemento encapsulando metadados usados pelo cliente de HTTP Streaming para fornecer o serviço de streaming para o usuário final. O elemento MediaPresentationDescription pode conter um ou mais dos seguintes atributos e elementos. Versão: número de versão para o protocolo para garantir a extensibilidade. PresentationIdentifier: informações tais que a apresentação possa ser identificada de forma exclusiva entre outras apresentações. Também pode conter campos privados/ocultos ou nomes. UpdateFrequency: freqüência de atualização da descrição de apresentação de mídia, ou seja, quantas vezes o cliente pode recarregar a descrição de apresentação de mídia real. Caso não esteja presente, a apresentação de mídia pode ser estática. Atualizar a apresentação de mídia pode significar que a apresentação de mídia não pode ser armazenada em cache. MediaPresentationDescriptionURI: URI para datar a descrição de apresentação de mídia. Stream: descreve o tipo de apresentação de fluxo ou mídia: texto, áudio ou vídeo. Um tipo de fluxo de vídeo pode conter áudio e pode conter texto. Serviço: descreve o tipo de serviço com atributos adicionais. Os tipos de serviço podem ser “ao vivo” e “sob demanda”. Isso pode ser usado para informar ao cliente que a procura/busca e acesso para além do tempo corrente não são permitidos. MaximumClientPreBufferTime: uma quantidade máxima de tempo que o cliente pode pré-acumular ou reservar a transmissão de mídia. Tal timing pode diferenciar o streaming/fluxo contínuo de download progressivo, caso o cliente esteja restrito para fazer o download para além deste tempo de pré-buffer máximo. O valor pode não estar presente, indicando que não se aplicam restrições em termos de pré- buffer. SafetyGuardIntervalLiveService: informações sobre o tempo máximo de “turn-around” de serviço ao vivo no servidor. Fornece uma indicação para o cliente sobre informações já acessíveis no momento atual. Tais informações podem ser necessárias caso se espere que o cliente e o servidor operem na hora UTC e nenhuma sincronização de tempo acurada é fornecida. TimeShiftBufferDepth: informações sobre quão longe o cliente pode retroceder em um serviço ao vivo com relação ao tempo atual. A extensão desta visualização em profundidade, em tempo deslocado pode ser admitida sem alterações específicas no provimento do serviço. LocalCachingPermitted: este parâmetro/flag indica se o cliente HTTP pode armazenar em cache os dados baixados localmente depois que eles foram reproduzidos. LivePresentationInterval: contém intervalos de tempo durante os quais a apresentação pode estar disponível, especificando StartTimes (instante de início) e EndTimes (instante de término). Um StartTime indica a hora de início dos serviços e o EndTime indica a hora de término do serviço. Se a hora de término não for especificada, então a hora de término é desconhecida no momento e o UpdateFrequency pode assegurar que os clientes obtém acesso ao tempo de final antes da hora de 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 horário especificada. O provimento do intervalo OnDemand, mudança/deslocamento de tempo adicional de visualização podem ser especificados. Este atributo também pode estar presente para um serviço ao vivo. Caso esteja presente para um serviço ao vivo, o servidor pode garantir que o cliente pode acessar o serviço como serviço OnDemand durante todos os intervalos de disponibilidade fornecidos. Portanto, o LivePresentationInterval não pode coincidir ou se sobrepor com qualquer OnDemandAvailabilityInterval. MPDFileInfoDynamic: Descreve a montagem/construção dinâmica padrão dos arquivos da apresentação de mídia. Mais detalhes são fornecidos abaixo. A especificação de padrão em nível MPD pode evitar a repetição desnecessária se forem usadas as mesmas regras para várias ou todas as representações alternativas. MPDCodecDescription: Descreve os CODECs padrão principais da apresentação de mídia. Mais detalhes são fornecidos abaixo. A especificação padrão ao nível da MPD pode evitar a repetição desnecessária caso sejam usados os mesmos CODECs para várias ou todas as representações. MPDMoveBoxHeaderSizeDoesNotChange: um sinalizador para indicar se o cabeçalho/header de MoveBox muda de tamanho entre os arquivos individuais dentro da apresentação de toda mídia. Este sinalizador pode ser usado para otimizar o download e só pode estar presente em caso de formatos específicos, especialmente aqueles para os quais segmentos contêm o cabeçalho moov. FileURIPattern: um padrão usado pelo cliente para gerar mensagens de solicitação para os arquivos dentro da apresentação de mídia. Diferentes atributos permitem geração de URIs exclusivos para cada um dos arquivos dentro da apresentação de mídia. O URI de base pode ser um URI de HTTP.

Representação Alternativa: Descreve uma lista de representações. Elemento AlternativeRepresentation:

[000206]Um elemento XML que encapsula todos os metadados para uma representação. O elemento AlternativeRepresentation pode conter os seguintes elementos e atributos. RepresentationID: um ID exclusivo para esta representação alternativa específica dentro da apresentação de mídia. FilesInfoStatic: fornece uma lista explícita dos tempos de partida/início e o URI de todos os arquivos de uma única apresentação alternativa. O provimento estático da lista de arquivos pode propiciar a vantagem de uma descrição de tempo exato da apresentação de mídia/meios de comunicação, mas pode não ser tão compacto, especialmente se a representação alternativa contém muitos arquivos. Além disso, os nomes dos arquivos podem ser nomes arbitrários. FilesInfoDynamic: oferece uma maneira implícita para construir a lista de tempos de partida e o URI de uma apresentação alternativa. O provimento dinâmico de lista de arquivos pode fornecer a vantagem de uma representação mais compacta. Se apenas a seqüência tempos de partida for fornecida, as vantagens de temporização/timing também valem aqui, porém os nomes dos arquivos devem ser construídos dinamicamente com base no FilePatternURI. Se apenas a duração de cada segmento for fornecida, a representação é compacta e pode ser adequada para uso em serviços live/ao vivo, mas a geração dos arquivos pode ser regulada pelo tempo global. APMoveBoxHeaderSizeDoesNotChange: Um flag/sinalizador que indica se o cabeçalho de MoveBox muda de tamanho entre os arquivos individuais dentro da descrição alternativa. Este sinalizador pode ser usado para otimizar o download e só pode estar presente em caso de formatos específicos, especialmente aqueles para os quais segmentos contêm o cabeçalho moov. APCodecDescription: descreve os principais CODECs de arquivos da 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 nesta representação. Especificamente, ele pode conter informações sobre as faixas/trilhas nesta apresentação alternativa, bem como agrupamentos recomendados de faixas, caso se aplique. O atributo MediaDescription contém os seguintes atributos: TrackDescription: Um atributo de XML que encapsula todos os metadados para a mídia que está contida nessa representação. O atributo de TrackDescription contém os seguintes atributos: TrackID: um ID exclusivo para o track/trilha dentro da representação alternativa. Ele pode ser usado no caso da trilha fazer parte de uma descrição de agrupamento. Bitrate: bitrate da faixa/trilha. TrackCodecDescription: Atributo de XML que contém todos os atributos no CODEC utilizado nesta faixa. O atributo de TrackCodecDescription 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 perfil e nível. LanguageTag: LanguageTag/marcador de linguagem/idioma, caso se aplique. MaxWidth/MaxHeight: para vídeo, a altura e largura do conteúdo de vídeo em pixels. SamplingRate: para taxa de amostragem de áudio. GroupDescription: um atributo que provê uma recomendação ao cliente para o agrupamento apropriado com base em diferentes parâmetros. GroupType: um tipo com base no qual o cliente pode decidir como agrupar faixas.

[000207]As informações em uma descrição de apresentação de mídia são vantajosamente usadas por um HTTP streaming de cliente para executar solicitações para arquivos/segmentos ou partes destes em momentos adequados, selecionando os segmentos a partir de representações adequadas que correspondam a seus recursos, por exemplo em termos de amplitude de banda de acesso, capacidades do display, recursos de codec e assim por diante, bem como as preferências do usuário, tais como o idioma e assim por diante. Além disso, como a descrição de mídia de apresentação descreve representações que estão alinhadas no tempo e mapeadas para um cronograma/timeline global, o cliente pode também usar as informações na MPD durante uma apresentação multimídia em curso para iniciar ações adequadas para alternar entre representações, apresentar representações conjuntamente ou procurar dentro da apresentação de mídia.

Sinalizando os Tempos/Instantes de Início de Segmentos

[000208]Uma representação pode ser dividida, em termo de tempo, em vários segmentos. Existe um problema de temporização inter-trilhas entre o último fragmento de um segmento e o próximo fragmento do próximo segmento. Além disso, existe outro problema de sincronia no caso de utilização de segmentos de duração constante.

[000209]O uso da mesma duração para cada segmento pode apresentar a vantagem de que o MPD é compacto e estático. No entanto, cada segmento ainda pode se iniciar em um ponto de acesso aleatório. Assim, a codificação de vídeo pode ser restringida para fornecer pontos de acesso aleatório nesses pontos específicos, ou as durações reais de segmentos podem não ser exatamente conforme especificado no MPD. Pode ser desejável que o sistema de streaming não coloque restrições desnecessárias sobre o processo de codificação de vídeo e assim a segunda opção pode ser preferida.

[000210]Especificamente, se a duração do arquivo for especificada no MPD como sendo de d segundos, então o n° arquivo pode começar com o ponto de acesso aleatório no, ou imediatamente após o, tempo/instante (n-1)°d.

[000211]Nesta abordagem, cada arquivo pode incluir informações como a hora exata de início do segmento em termos de tempo de apresentação global. Três maneiras possíveis para sinalizar isto incluem: (1) Em primeiro lugar, restringir o horário de início de cada segmento para o tempo/instante exato conforme especificado no MPD. Mas então o codificador de mídia pode não ter qualquer flexibilidade sobre o posicionamento dos quadros IDR e pode exigir codificação especial para o arquivo de streaming. (2) Segundo, adicionar a hora de início exata para o MPD para cada segmento. No caso de demanda, a compacidade do MPD pode ser reduzida. Para o caso ao vivo, isso pode exigir uma atualização regular do MPD, o que pode reduzir a capacidade de expansão. (3) Em terceiro lugar, adicionar o tempo global ou a hora de início exato relativo para o tempo de começo anunciado da representação ou a hora de início anunciadas do segmento no MPD para o segmento no sentido de que o segmento contenha essas informações. Isso pode ser adicionado a um box/caixa nova dedicada ao streaming adaptativo. Esta caixa também pode incluir as informações previstas pela caixa de "TIDX" ou "SIDX". Uma conseqüência dessa terceira abordagem é que, quando se procura uma posição específica no começo de um dos segmentos, o cliente pode, baseado no MPD, escolher o segmento posterior àquela que contém o ponto necessário de busca. Uma resposta simples, neste caso, pode ser mover o ponto de busca para frente para o início do segmento recuperado (ou seja, para o próximo ponto de acesso aleatório após o ponto de busca). Normalmente, os pontos de acesso aleatório são fornecidos pelo menos a cada poucos segundos (e muitas vezes há pouco ganho de codificação em torná- los menos freqüentes) e, portanto, no pior caso o ponto de busca pode ser movido para ocorrer alguns segundos mais tarde do que o especificado. Como alternativa, o cliente poderia determinar em recuperar as informações de cabeçalho para o segmento ao qual o ponto de busca requerido está de fato no segmento anterior e solicitar esse segmento em seu lugar. Isso pode resultar em um aumento ocasional do tempo necessário para executar a operação de busca.

Lista de Segmentos Acessíveis

[000212]A apresentação de mídia compreende um conjunto de representações, cada uma delas fornecendo alguma versão diferente da codificação do conteúdo de mídia original. As representações vantajosamente contêm informações sobre os parâmetros de diferenciação da representação em comparação com os outros parâmetros. Eles também contêm, explícita ou implicitamente, uma lista de segmentos acessíveis.

[000213]Os segmentos podem ser diferenciados entre segmentos sem-tempo ou não temporizados contendo somente metadados e segmentos de mídia que contêm principalmente dados de mídia. A descrição de apresentação de mídia (MPD) vantajosamente identifica e designa atributos diferentes a cada um dos segmentos, implicitamente ou explicitamente. Atributos vantajosamente atribuídos a 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. Além disso, segmentos de mídia vantajosamente recebem atributos, como a hora de início do segmento da apresentação de meios de comunicação social e da duração do segmento da apresentação de mídia.

[000214]Quando a apresentação de mídia for do tipo "on demand", tal como vantajosamente indicado por um atributo na descrição de apresentação da mídia, como o OnDemandAvailabilityInterval, a descrição de apresentação de mídia normalmente descreve os segmentos inteiros e também fornece indicação quando os segmentos são acessíveis e quando os segmentos não são acessíveis. As horas de início de segmentos vantajosamente são expressas com relação ao início da apresentação multimídia de tal modo que dois clientes começando a reprodução das mesmas apresentações de mídia, mas em momentos diferentes, podem usar a mesma descrição de apresentação de mídia/meios de comunicação, bem como os mesmos segmentos de mídia. Vantajosamente, isso melhora a capacidade de armazenar em cache os segmentos.

[000215]Quando a apresentação de mídia é do tipo “ao vivo”, como vantajosamente indicado por um atributo na descrição de apresentação da mídia, tal como o atributo Service, os segmentos que compreende a apresentação de mídia além da hora real do dia não são geralmente gerados ou pelo menos não estão acessíveis apesar dos segmentos estarem totalmente descritos no MPD. No entanto, com a indicação de que o serviço de apresentação de mídia é do tipo ao vivo, o cliente pode produzir uma lista de segmentos acessíveis junto com os atributos de sincronia para o tempo interno do cliente NOW em termos de hora/tempo de relógio convencional, com base nas informações constantes do MPD e o tempo de download do MPD. O servidor vantajosamente opera no sentido de que torna o recurso acessível, de tal forma que um cliente de referência, operando com a instância do MPD na hora de relógio NOW possa acessar os recursos.

[000216]Especificamente, o cliente de referência produz uma lista de segmentos acessíveis junto com os atributos de sincronia para um tempo interno do cliente NOW em tempo de relógio, com base nas informações contidas no MPD e no tempo de download do MPD. Com o avanço do tempo, o cliente usará o mesmo MPD e irá criar uma nova lista de segmentos acessíveis que pode ser usada para reproduzir continuamente a apresentação de mídia. Portanto, o servidor pode anunciar segmentos em um MPD antes que estes segmentos estejam realmente acessíveis. Isto é vantajoso pois reduz a freqüência de atualização e downloads do MPD.

[000217]Vamos presumir que uma lista de segmentos, cada um com a hora de início, tS, seja descrita explicitamente por uma lista de reprodução em elementos tais como FileInfoStatic ou implicitamente, usando um elemento, como FileInfoDynamic. Um método vantajoso para gerar uma lista de segmento usando FileInfoDynamic será descrito mais adiante. Com base nesta regra de construção, o cliente tem acesso a uma lista de URIs para cada representação, r, aqui referida como FileURI(r,i), e uma hora de início, tS(r,i), para cada segmento com índice i.

[000218]A utilização de informações no MPD para criar a janela de tempo acessível de segmentos pode ser executada usando-se as seguintes regras.

[000219]Para um serviço do tipo "on demand", tal vantajosamente indicada por um atributo tal como Service, caso a hora de relógio no cliente agora esteja dentro de qualquer intervalo de disponibilidade, vantajosamente expressado por um elemento MPD, tal como OnDemandAvailabilityInterval, todos os segmentos descritos desta apresentação On Demand são acessíveis. Caso a hora de relógio atual no cliente esteja fora de qualquer intervalo da disponibilidade, então nenhum dos segmentos descritos desta apresentação On Demand estarão acessíveis.

[000220]Para um serviço do tipo "ao vivo", tal como vantajosamente indicado por um atributo, como Service, instante de início, tS(r,i), vantajosamente exprime o tempo de disponibilidade em hora de relógio. A hora de início de disponibilidade pode ser derivada como uma combinação de tempo/instante de serviço ao vivo do evento e algum tempo de turn around no servidor para captura, codificação e publicação. O tempo para este processo pode, por exemplo, ser especificado no MPD, por exemplo usando um intervalo de guarda de segurança tG especificado por como SafetyGuardIntervalLiveService no MPD. Isso proporcionaria a diferença mínima entre a hora UTC e a disponibilidade dos dados no servidor de fluxo contínuo de HTTP. Em outra modalidade, o MPD especifica explicitamente o tempo de disponibilidade do segmento no MPD sem fornecer o tempo de turn around na forma de uma diferença entre a hora do evento ao vivo e o tempo de turn-around. As descrições que se seguem presumem que quaisquer tempos globais são especificados como tempos de disponibilidade. Os técnicos na área de broadcast de mídia ao vivo podem derivar tais informações a partir de informações adequadas na descrição de apresentação da mídia após ler a presente descrição.

[000221]Caso a hora de relógio atual no cliente, NOW, esteja fora de qualquer intervalo do intervalo de apresentação ao vivo, vantajosamente expressa por um elemento MPD, tal como LivePresentationInterval, nenhum dos segmentos descritos desta apresentação ao vivo são acessíveis. Se a hora de relógio atual NOW no cliente estiver dentro do intervalo de apresentação ao vivo, pelo menos alguns segmentos dos segmentos descritos desta apresentação ao vivo podem estar acessíveis.

[000222]A restrição dos segmentos acessíveis é regida pelos seguintes valores:

[000223]A hora de relógio NOW (tal como disponível para o cliente).

[000224]A profundidade/alcance permitido para o buffer de deslocamento temporal tTSB, por exemplo especificado como TimeShiftBufferDepth na descrição de apresentação da mídia.

[000225]Um cliente no instante de evento relativo tl só pode solicitar segmentos com horas de início tS(r, i) no intervalo de (NOW - tTSB) e NOW (agora) ou em um intervalo tal que a hora de término do segmento com duração d seja também incluída, resultando em um intervalo de (NOW - tTSB d) e NOW.

Atualizando o MPD

[000226]Em algumas modalidades, o servidor não conhece antecipadamente o localizador de arquivo ou de segmento e as horas/instantes de início dos segmentos, dado que, por exemplo, se a localização do servidor irá mudar, ou se a apresentação de mídia inclui algum anúncio/propaganda de um servidor diferente, ou a duração da apresentação de mídia é desconhecida, ou o servidor quer ocultar o localizador para os segmentos a seguir.

[000227]Em tais modalidades, o servidor só poderia descrever segmentos que já estão acessíveis ou que ficarão acessíveis logo após a publicação desta instância do MPD. Ademais, em algumas modalidades, o cliente consome vantajosamente mídia próximos dos mídia/meios de comunicação descritos no MPD, de tal modo que o usuário experimenta o programa de mídia contido tão próximo quanto possível para a geração de conteúdo de mídia. Assim que o cliente antecipa que chega ao fim dos segmentos de mídia descritos no MPD, vantajosamente solicita uma nova instância do MPD para continuar a reprodução na expectativa de que o servidor tenha publicado um novo MPD descrevendo novos segmentos de mídia. O servidor vantajosamente gera novas instâncias do MPD e atualiza o MPD com os quais os clientes podem contar com os procedimentos para atualizações contínuas. O servidor pode adaptar seus procedimentos de atualização de MPD junto com a geração de segmentos e a publicação dos procedimentos de um cliente de referência que age como um cliente comum poderia agir.

[000228]Caso uma nova instância do MPD descreve apenas um curto avanço no tempo então os clientes devem requisitar freqüentemente novas instâncias do MPD. Isso pode resultar em problemas de escalonamento ou expansão e tráfego de uplink e downlink desnecessário devido a solicitações desnecessariamente freqüentes.

[000229]Por conseguinte, é pertinente por um lado descrever segmentos tanto quanto possível no futuro sem necessariamente torná-los logo acessíveis, e por outro lado habilitar atualizações não previstas do MPD para expressar novos locais de servidor, permitir a inserção de novos conteúdos, tais como propagandas, ou fornecer mudanças nos parâmetros de codec.

[000230]Além disso, em algumas modalidades, a duração dos segmentos de mídia pode ser pequena, tal como na faixa de alguns segundos. A duração dos segmentos de mídia é vantajosamente flexível de modo a se ajustar ao tamanho de segmento adequado que pode ser otimizado para transporte ou propriedades de cache, para compensar o atraso de ponta a ponta em serviços live/ao vivo, ou outros aspectos que lidam com armazenamento ou entrega de segmentos, ou por outras razões. Especialmente nos casos em que os segmentos são pequenos em comparação com o período de apresentação de mídia, então uma quantidade significativa de recursos do segmento de mídia e tempos/instantes de início precisarão ser descritos na descrição de apresentação da mídia. Como resultado, o tamanho da descrição da apresentação de mídia pode ser grande, o que pode afetar negativamente o tempo de download na descrição de apresentação de mídia e, por conseguinte, afetar o retardo de partida/inicialização da apresentação multimídia e também o uso de amplitude de banda no link de acesso. Portanto, é vantajoso não só permitir a descrição de uma lista de segmentos de mídia usando listas de reprodução, mas também permitir a descrição usando modelos ou regras de construção de URL. Nesta descrição, os termos modelos e regras de construção de URL são usadas como sinônimos.

[000231]Além disso, modelos podem vantajosamente ser usados para descrever localizadores de segmento em casos ao vivo para além do tempo atual. Em tais casos, atualizações do MPD são por si só desnecessárias, dado que os localizadores, bem como a lista de manobras estão descritos pelos modelos. No entanto, acontecimentos imprevistos ainda podem ocorrer, exigindo alterações na descrição das representações ou segmentos. Alterações em uma descrição de apresentação de mídia de fluxo contínuo/streaming de HTTP adaptativo podem ser necessárias quando o conteúdo de várias fontes diferentes é emendado, por exemplo quando uma publicidade for inserida. O conteúdo de diferentes fontes pode diferir em uma variedade de maneiras. Outra razão, durante as apresentações ao vivo, é que pode ser necessário alterar os URLs usados para arquivos de conteúdo para prever fail-over/repasse em caso de falha, de uma origem ao vivo de um servidor para outro.

[000232]Em algumas modalidades, é vantajoso que, caso o MPD seja atualizado, as atualizações para o MPD são realizadas de modo a que o MPD atualizado seja compatível com o MPD anterior no sentido de que o cliente de referência e, portanto, qualquer cliente implementado, gere uma lista identicamente funcional dos segmentos acessíveis a partir do MPD atualizado para qualquer época até o tempo de validade do MPD anterior, tal como ele teria feito da instância anterior do MPD. Este requisito garante que (a) os clientes podem começar imediatamente a usar o MPD novo sem sincronização com o MPD antigo, uma vez que ele é compatível com o MPD antigo antes do momento de atualização; e (b) o momento de atualização não precisa estar sincronizado com o momento em que ocorre a mudança real para o MPD. Em outras palavras, atualizações para o MPD podem ser anunciadas antecipadamente, e o servidor pode substituir a instância antiga do MPD depois que novas informações estejam disponíveis, sem ter que manter diferentes versões do MPD.

[000233]Podem ocorrer duas possibilidades para sincronia de mídia através de uma atualização MPD para um conjunto de representações ou todas as representações. Ou (a) o cronograma global existente continua em toda a atualização MPD (aqui referida como uma “atualização contínua de MPD”), ou (b) as linha do tempo/cronograma atual termina e um novo cronograma começa com o segmento seguinte à alteração (aqui referida como uma “atualização de MPD descontínua”).

[000234]A diferença entre essas opções pode ficar evidente quando se considera que as faixas/trilhas de um fragmento de mídia e, portanto, de um segmento, geralmente não começam e terminam ao mesmo tempo por causa da diferente granulação/resolução de amostra entre as faixas. Durante a apresentação normal, amostras de uma faixa de um fragmento podem ser processadas antes de algumas amostras de outra faixa do fragmento anterior, ou seja existe algum tipo de sobreposição entre fragmentos apesar de não existir sobreposição dentro de uma única faixa.

[000235]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 ocorre por causa do splicing/emenda de conteúdos completamente separados, tal sobreposição é geralmente difícil de conseguir, dado que o novo conteúdo precisa nova codificação para ser emendado com o conteúdo anterior. Por conseguinte, afigura-se vantajoso possibilitar a capacidade para atualização descontínua da apresentação de mídia, reiniciando o cronograma para determinados segmentos e possivelmente também definindo um novo conjunto de representações após a atualização. Além disso, caso o conteúdo tenha sido independentemente codificado e segmentado, então ele é também evitado para ajustar marcas de tempo/timestamps de modo a se ajustar ao cronograma global da parte anterior do conteúdo.

[000236]Quando a atualização ocorre por razões menores, tal como apenas pela adição de novos segmentos de mídia à lista de segmentos de mídia, ou se o local dos URL for alterado, então podem ser permitidas sobreposições e atualizações contínuas.

[000237]No caso de uma atualização de MPD descontínua, a linha da tempo do último segmento da representação anterior termina no fim do tempo da mais recente apresentação de qualquer amostra no segmento. A linha do tempo da próxima representação (ou, mais precisamente, o primeiro instante de apresentação do primeiro segmento de mídia da nova parte da apresentação de meios de comunicação/midia, também referido como novo período) típica e vantajosamente se inicia no mesmo instante que o fim da apresentação do último período tal que se assegure uma reprodução perfeita e contínua.

[000238]Os dois casos estão ilustrados da Figura 11.

[000239]É preferido e vantajoso restringir as atualizações MPD aos limites do segmento. A lógica para se limitar tais mudanças ou atualizações aos limites do segmento é como se segue. Em primeiro lugar, as alterações nos metadados binários para cada representação, normalmente o cabeçalho de filme, podem ter lugar pelo menos nos limites do segmento. Em segundo lugar, a descrição de apresentação de mídia pode conter os ponteiros/pointers (URLs) para os segmentos. Em um sentido, o MPD é a estrutura de dados de “guarda- chuva”/abrangente, que reúne todos os arquivos de segmento associados com a apresentação de mídia. Para manter esta relação de confinamento, cada segmento pode ser referenciado por um único MPD e quando o MPD é atualizado, ele vantajosamente somente é atualizado em um limite de segmento.

[000240]Os limites de segmento não necessitam de um modo geral estar alinhados, porém para o caso de conteúdo emendado de diferentes fontes e atualizações de MPD descontínuas, geralmente faz sentido alinhar os limites de segmento (especificamente, que o último segmento de cada representação possa terminar no mesmo quadro de vídeo e não possa conter amostras de áudio com uma hora de início de apresentação posterior ao instante de apresentação do quadro). Uma atualização descontínua pode então iniciar um novo conjunto de representações cada vez em um instante comum, designado como período. A hora de início da validade desse novo conjunto de representações é fornecida, por exemplo, por uma hora de início do período. A hora de início relativa de cada representação é redefinida para zero e a hora de início do período coloca o conjunto das representações neste novo período na linha da tempo de apresentação de mídia global.

[000241]Para atualizações contínuas do MPD, os limites de segmento não são obrigados a estar alinhados. Cada segmento de cada representação alternativa pode ser regido por uma única descrição de apresentação de mídia e, assim, a atualização solicita para uma nova instância de uma descrição de apresentação de mídia, geralmente desencadeada pela antecipação de que nenhum segmento de mídia adicional estejam descritos no MPD em operação, podem realizar-se em momentos diferentes, dependendo do conjunto de representações consumido, incluindo o conjunto das representações que se espera ser consumido.

[000242]Para oferecer suporte a atualizações nos elementos e atributos de MPD em um caso mais geral, quaisquer elementos, não somente representações ou conjunto de representações, podem ser associados a um tempo de validade. Dessa forma, caso determinados elementos do MDP precisam ser atualizados, por exemplo quando o número de observações for alterado, ou as regras de construção de URL forem alteradas, tais elementos podem ser atualizados individualmente, em momentos especificados, fornecendo várias cópias do elemento com tempos de validade disjuntos.

[000243]A validade é vantajosamente associada com o tempo de mídia global, tal que o elemento descrito associado a um tempo de validade é válido em um período do cronograma/timeline global da apresentação de mídia.

[000244]Tal como foi acima descrito, em uma modalidade os tempos de validade somente são adicionados a um conjunto completo de representações. Cada conjunto completo então forma um período. O tempo de validade, em seguida, forma a hora de início do período. Em outras palavras, em um caso específico do uso do elemento de validade, um conjunto completo de representações pode ser válido por um período de tempo, indicado por um tempo de validade global de um conjunto de representações. O tempo de validade de um conjunto de representações é referido como um período. No início de um novo período, expira a validade da representação de conjunto anterior e o novo conjunto de representações é válido. Note-se novamente que os tempos de validade dos períodos são preferencialmente separados ou desconexos.

[000245]Como foi mencionado acima, as alterações da descrição de apresentação de mídia ocorrem nos limites do segmento e assim, para cada representação, a alteração de um elemento realmente ocorre no limite do próximo segmento. O cliente então pode formar um MPD válido, incluindo uma lista de segmentos para cada instante de tempo dentro do prazo de apresentação dos meios de comunicação.

[000246]A emenda de blocos descontínua pode ser adequada nos casos em que os blocos contêm dados de mídia de diferentes representações, ou de conteúdo diferente, por exemplo de um segmento de conteúdo e uma propaganda, ou em outros casos. Pode ser necessária em um sistema de streaming por solicitação de blocos que alterações aos metadados de apresentação ocorrem apenas nos limites de blocos do sistema de streaming. Isso pode ser vantajoso para razões de implementação porque o atualizar parâmetros de decodificador de mídia dentro de um bloco pode ser mais complexo do que atualiza-los somente entre blocos. Neste caso, vantajosamente, pode ser especificado que intervalos de validade conforme descrito acima podem ser interpretados como aproximados, tal que um elemento seja considerado válido desde o primeiro limite de bloco não anterior ao início do intervalo de validade especificado para o primeiro limite de bloco, não antes do termo do intervalo de validade especificado.

[000247]Uma modalidade exemplar do que foi acima descrito descreve novos aperfeiçoamentos para um sistema de streaming por requisição de blocos descritos mais adiante na seção Alterações em Apresentações de Mídia.

Sinalização de Duração de Segmento

[000248]Atualizações descontínuas efetivamente dividem a apresentação em uma série de intervalos desconexos, designados como períodos. Cada período tem sua própria linha do tempo para temporização de amostras de mídia. O timing de mídia de representação dentro de um período pode ser vantajosamente indicado especificando-se uma lista compacta separada das durações de segmento para cada período ou para cada representação em um período.

[000249]Um atributo, por exemplo referido como período de tempo de partida ou inicialização, associado a elementos dentro do MPD, pode especificar o tempo de validade de determinados elementos dentro do prazo de apresentação de mídia. Esse atributo pode ser adicionado para quaisquer elementos (atributos que podem ser designados com uma validade podem ser alterados para elementos) do MPD.

[000250]Para atualizações de MPD descontínuas os segmentos de todas as representações pode terminar na descontinuidade. Isso geralmente implica, pelo menos, que o último segmento antes da descontinuidade tem uma duração diferente dos anteriores. A duração do segmento de sinalização pode envolver indicar se todos os segmentos têm a mesma duração ou indicar uma duração separada para cada segmento. É desejável que haja uma representação compacta para uma lista de durações de segmentos que seja eficiente nos casos em que muitos deles têm a mesma duração.

[000251]As durações de cada segmento em uma representação ou um conjunto de representações vantajosamente podem ser efetuadas com uma única seqüência/string de caracteres que especifica todas as durações de segmento para um intervalo único desde o início da atualização descontínua, isto é, o início do período até o último segmento de mídia descrito no MPD. Em uma modalidade, o formato desse elemento é uma seqüência/string 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 uma duração atributo dur e um multiplicador opcional mult do atributo, indicando que esta representação contém <mult> dos primeiros segmentos de entrada de duração <dur> da primeira entrada, em seguida <mult> dos segmentos de segunda entrada de duração <dur> da segunda entrada e assim por diante.

[000252]Cada entrada de duração especifica a duração de um ou mais segmentos. Se o valor de <dur> seja seguido pelo caractere “*” e um número, esse número especifica o número de segmentos consecutivos com tal duração, em segundos. Se o sinal de multiplicador “*” estiver ausente, o número de segmentos é um. Se o “*” está presente sem qualquer número em seguida, todos os segmentos subseqüentes têm a duração especificada e não pode haver quaisquer outras entradas na lista. Como exemplo, o string de caracteres “30*” significa que todos os segmentos têm uma duração de 30 segundos. A seqüência de caracteres “30*12 10.5” indica 12 segmentos de duração de 30 segundos, seguido por um com duração de 10,5 segundos.

[000253]Caso as durações de segmento sejam especificadas separadamente para cada representação alternativa, então a soma das durações de segmento dentro de cada intervalo pode ser a mesma para cada representação. No caso de faixas/trilhas de vídeo, o intervalo pode terminar no mesmo quadro em cada representação alternativa.

[000254]Os técnicos na área, ao lerem a presente descrição, podem encontrar formas semelhantes e equivalentes para expressar as durações de segmento de uma forma compacta.

[000255]Em outra modalidade, a duração de um segmento é sinalizada como sendo constante para todos os segmentos da representação exceto para o ú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, contanto que o ponto de início da próxima atualização descontínua ou o início de um novo período sejam fornecidos, 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 de Metadados de Representação

[000256]As indicações de alterações de metadados de representação binários codificados tais como mudanças no header de filme “moov” podem ser efetuadas de diferentes formas: (a) pode haver uma caixa/box moov para todas as representações em um arquivo separado relacionado no MPD, (b) pode haver uma caixa moov para cada representação alternativa em um arquivo separado relacionado em cada representação alternativa, (c) cada segmento pode conter uma caixa moov e portanto é portanto está auto-contido, (d) pode haver uma caixa moov para todas as representações em um arquivo 3GP juntamente com o MPD.

[000257]Note-se que nos casos (a) e (b), o “moov” único poderá ser vantajosamente combinado com o conceito de validade acima em um sentido de que mais caixas “moov” podem ser referenciadas em um MPD, desde que as suas validades sejam desconexas. Como exemplo, com a definição de um limite de período, pode expirar a validade do “moov” no período antigo com o início do novo período.

[000258]No caso da opção (a), a referência à caixa moov única pode ser atribuída um elemento de validade. Vários cabeçalhos de apresentação podem ser permitidos, porém apenas um pode ser válido de cada vez. Em outra modalidade, o tempo de validade de todo o conjunto das representações em um período, ou a totalidade do período, tal como definido acima, pode ser usado como um tempo de validade para esses metadados de representação, normalmente fornecidos na forma de do cabeçalho moov.

[000259]No caso da opção (b), caso a referência à caixa moov de cada representação pode receber um elemento de validade. Vários cabeçalhos de representação podem ser permitidos, mas apenas um pode ser válido por vez. Em outra modalidade, o tempo de validade da representação inteira ou todo o período como definido acima pode ser usado como um tempo de validade para esses metadados de representação, normalmente fornecidos como o cabeçalho moov.

[000260]No caso da opção (c), não pode ser adicionada qualquer sinalização no MPD, mas sinalização adicional no fluxo de mídia pode ser adicionado para indicar se a caixa moov vai mudar para qualquer dos segmentos próximos. Isso será explicado mais adiante no contexto da "Sinalização de Atualizações Dentro de Metadados de Segmentos”.

Sinalização de Atualizações Dentro de Metadados de Segmentos

[000261]Para evitar atualizações freqüentes na descrição de apresentação de mídia, para obter conhecimento sobre possíveis atualizações, é vantajoso sinalizar quaisquer de tais atualizações junto com os segmentos de mídia. Pode ser provido um elemento ou elementos adicionais dentro dos próprios segmentos de mídia, os quais podem indicar que metadados atualizados, tais como a descrição de apresentação de mídia, estão disponíveis e devem ser acessados dentro de um determinado período de tempo para continuar com sucesso a criação de listas de segmentos acessíveis. Além disso, tais elementos podem fornecer um identificador de arquivo, como um URL, ou informações que podem ser usadas para construir um identificador de arquivo, para o arquivo de metadados atualizado. O arquivo de metadados atualizado pode incluir metadados iguais aos que são fornecidos no arquivo de metadados original para a apresentação modificados para indicar intervalos de validade juntamente com 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 que acessa um sistema de streaming por requisições de blocos, ao detectar essa indicação dentro de um bloco de mídia, pode utilizar o protocolo de download de arquivo ou outros meios para recuperar o arquivo de metadados atualizados. O cliente é assim fornecido com informações sobre alterações na descrição de apresentação de mídia e o momento em que elas 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 “sondar” e receber o arquivo muitas vezes para possíveis atualizações ou alterações.

[000262]Os exemplos de alterações de adição ou remoção de representações, alterações em uma ou mais representações, tais como alteração na taxa de bits, resolução, razão de aspecto, faixas/trilhas ou codec parâmetros incluídos, e alterações das regras de construção de URL, por exemplo um servidor de origem diferentes para um anúncio. Algumas alterações podem afetar apenas o segmento de inicialização, como o “átomo” de header/cabeçalho de filme (moov) associado a uma representação, enquanto que outras alterações possam afetar a descrição de apresentação de mídia (MPD).

[000263]No caso de conteúdo por demanda, essas alterações e respectivo timing podem ser conhecidas com antecedência e poderiam ser sinalizados na descrição de apresentação de mídia.

[000264]Para conteúdo live/ao vivo, as alterações não podem ser conhecidas até o ponto em que elas ocorrem. Uma solução é permitir que a descrição de apresentação de mídia disponível em uma URL específica seja atualizada dinamicamente e exigir que os clientes solicitem regularmente tal MPD para detectar alterações. Esta solução apresenta desvantagem em termos de escalonamento (eficiência de carga e o cache do servidor origem). Em um cenário com um grande número de espectadores, os caches podem receber muitas solicitações para o MPD depois que a versão anterior houver expirado do cache e antes que a nova versão seja recebida e todos possam ser encaminhados para o servidor de origem. O servidor de origem pode necessitar constantemente processar solicitações de caches para cada versão atualizada do MPD. Além disso, as atualizações não podem ser facilmente alinhadas no tempo com as alterações na apresentação de mídia.

[000265]Dado que uma das vantagens do fluxo contínuo/streaming HTTP é a capacidade de utilizar a infra-estrutura padrão da web e serviços para escalonamento, uma solução preferida pode envolver apenas arquivos (ou seja, cache) “estáticos” e não depender de clientes “sondarem” arquivos para constatar se eles mudaram.

[000266] Soluções são discutidas e propostas para resolver a atualização de metadados, incluindo a descrição de apresentação de mídia e metadados binários de representação tais como átomos moov em uma apresentação de mídia de fluxo contínuo HTTP adaptável.

[000267]Para o caso de conteúdo ao vivo, os pontos em que podem ser alterados o MPD ou moov poderiam não ser conhecidos quando o MPD é construído. Como a freqüente sondagem do MPD para verificar se há atualizações deve geralmente ser evitado, por razões de amplitude de banda e escalonamento, as atualizações para o MPD podem ser indicadas “em banda” nos arquivos de segmento, ou seja, que cada segmento de mídia pode ter a opção para indicar atualizações. Dependendo do formatos de segmentos (a) a (c) acima, podem ser sinalizadas diferentes atualizações.

[000268]De um modo geral, a seguinte indicação pode vantajosamente ser fornecida em um sinal dentro do segmento: um indicador de que o MPD pode ser atualizado antes de solicitar o próximo segmento dentro desta representação ou qualquer segmento seguinte que tem hora de início maior do que a hora de início do segmento atual. A atualização pode ser anunciada antecipadamente, indicando que a atualização só precisa acontecer, o mais tardar, em qualquer segmento seguinte. Esta atualização MPD também pode ser usada para atualizar os metadados binários de representação como cabeçalhos/headers de filme no caso do localizador do segmento de mídia ser alterado. Outro sinal pode indicar que com a conclusão deste segmento, não devem ser solicitados mais nenhum segmento que adiantem o tempo.

[000269]Caso os segmentos sejam formatados de acordo com o formato de segmento (c), isto é, cada segmento de mídia pode conter metadados auto- inicializados metadados, como o cabeçalho de filme, então mais outro sinal pode ser adicionado indicando que o segmento subseqüente contém um cabeçalho de filme atualizado (moov). Isto permite vantajosamente que o cabeçalho de filme possa ser incluído no segmento, mas o cabeçalho de filme só precisa ser solicitado pelo cliente caso o segmento anterior indique uma atualização do cabeçalho de filme ou no caso de busca ou acesso aleatório ao comutar representações. Em outros casos, o cliente pode emitir uma solicitação de intervalo de byte para o segmento que exclui o cabeçalho de filme do download, portanto vantajosamente poupando amplitude de banda.

[000270]Em mais outra modalidade, caso a indicação de atualização de MPD seja sinalizada, então o sinal também pode conter um localizador como o URL para a descrição atualizada de apresentação de mídia. A MPD atualizada pode descrever a apresentação tanto antes como depois da atualização, usando os atributos de validade como um período novo e antigo em caso de atualizações descontínuos. Isso pode ser vantajosamente utilizado para permitir a exibição com mudança de tempo, tal como descrito mais adiante, mas também permite vantajosamente a atualização MPD ser sinalizada a qualquer momento antes das alterações que nela tenham efeito. O cliente pode imediatamente download o MPD novo e aplicá-lo à apresentação em curso.

[000271]Em uma realização específica, a sinalização de qualquer alteração da descrição de apresentação de mídia, dos moov headers, ou no final da apresentação, pode estar contida em uma caixa/box de informações formatado de acordo com as regras do formato de segmento usando a estrutura de box do formato de arquivo de mídia de base ISO. Esta caixa pode fornecer um sinal específico para qualquer uma das diferentes atualizações. Caixa/Box de Informações de Streaming Definição Tipo de caixa: “sinf” Container: nenhum Obrigatória: não Quantidade: Zero ou um.

[000272]A caixa de informações de streaming contém informações sobre a apresentação de streaming/fluxo contínuo do qual o arquivo é uma parte. Sintaxe aligned(8) class StreamingInformationBox extends FullBox('sinf') { unsigned int(32) streaming_information_flags; Os que se seguem são campos opcionais: String MPD_location } Semântica streaming_information_flags contém o OR lógico de zero ou mais dos seguintes: 0 x 00000001 Movie Header update follows 0 x 00000002 Presentation Description update 0x00000004 end-of-presentation mpd_location está presente somente se os sinalizadores/flags Presentation Description update estiverem ativos e fornece um URL (localizador de recursos uniforme) para a nova apresentação descrição da mídia.

Exemplo de Caso de Uso para Atualizações MPD para Serviços Live/Ao Vivo

[000273]Vamos supor que um provedor de serviço deseja fornecer um evento de futebol ao vivo usando o streaming por requisição de blocos ampliado aqui descrito. Talvez milhões de usuários podem querer acessar a apresentação do evento. O evento ao vivo esporadicamente é interrompido por intervalos por exemplo o intervalo entre um tempo e outro, ou outra pausa, tal como uma parada técnica, na ação, durante o qual os anúncios/propaganda poderão ser veiculados. Normalmente, não há nenhuma ou pouca antecedência do momento exato das interrupções.

[000274]O provedor de serviços precisará de uma infraestrutura redundante (por exemplo, codificadores e servidores) para possibilitar uma comutação sem interrupções no caso de falha de algum dos componentes durante o evento ao vivo.

[000275]Vamos supor que um usuário, chamada Anna, acessa o serviço em um ônibus com seu dispositivo móvel e o serviço está disponível imediatamente. Próximo a ela encontra-se um outro usuário, Paul, que assiste o evento em seu laptop. Um gol é marcado e ambos celebram este evento ao mesmo tempo. Paul diz a Anna que o primeiro gol do jogo foi ainda mais emocionante e Anna usa o serviço para que ela possa assistir o evento 30 minutos atrás. Depois de ter visto o gol, ela volta para o evento ao vivo.

[000276]Para lidar com esse caso de utilização, o provedor de serviço deve ser capaz de atualizar o MPD, sinalizar para os clientes de que um MPD atualizado está disponível, e permitir o acesso de clientes ao serviço de streaming de tal forma que ele possa apresentar os dados em tempo quase real.

[000277]A atualização do MPD é viável de maneira assíncrona para a distribuição de segmentos, tal como foi aqui descrito em outro local. O servidor pode fornecer garantias ao receptor de que um MPD não é atualizado há algum tempo. O servidor pode se basear no MPD atual. No entanto, nenhuma sinalização explícita é necessária quando o MPD é atualizado antes de algum período mínimo de atualização.

[000278]Uma reprodução completamente síncrona dificilmente é alcançada dado que o cliente pode operar em diferentes instâncias do MPD e, por conseguinte, os clientes podem apresentar um certo grau de “deriva”. Usando atualizações MPD, o servidor pode transmitir as alterações e os clientes podem ser alertados sobre as alterações, mesmo durante uma apresentação. A sinalização “in-band” em uma base de segmento a segmento pode ser usada para indicar a atualização do MPD, de forma a que as atualizações podem ser limitadas aos limites do segmento, mas isto deve ser aceitável na maioria das aplicações.

[000279]Um elemento de MPD pode ser adicionado, provendo o tempo de publicação em “tempo de relógio” do MPD, bem como uma caixa de atualização MPD opcional que é adicionada no início de segmentos para sinalizar que é necessária uma atualização MPD. As atualizações podem ser feitas de forma hierárquica, tal como acontece com as MPDs.

[000280]O “Tempo/Instante de publicação” fornece um identificador exclusivo para o MPD e de quando o MPD foi emitido. Ele também fornece uma âncora ou referência para os procedimentos de atualização.

[000281]A caixa de atualização do MPD pode ser encontrada no MPD após a caixa/box “styp” e definida por um tipo de box/caixa = “mupe”, não precisando de nenhum container, não sendo obrigatória e com uma quantidade de zero ou um. A caixa de atualização MPD contém informações sobre a apresentação da mídia da qual o segmento é uma parte.

[000282]Um exemplo de sintaxe é como se segue: aligned(8) class MPDUpdateBox extends FullBox('mupe') { unsigned int(3) mpd information flags; unsigned int(l) new-location flag; unsigned int(28) latest_mpd_update_time; /// Os que se seguem são campos opcionais String MPD_location } A semântica dos vários objetos do class MPDUpdateBox pode ser a seguinte: mpd_information_flags: o OR lógico de zero ou mais dos seguintes: 0x00 - atualização de descrição de apresentação de mídia agora 0x01 - atualização de descrição de apresentação de mídia a frente 0x02 - final de apresentação 0x03 a 0x07 - reservados. New_location flag: caso definido como 1, então a nova descrição de apresentação de mídia está disponível em um novo local especificado em mpd_location. latest_mpd_update time: Especifica o tempo (em ms) por quando a atualização MPD é necessária em relação ao tempo de emissão MPD do MPD mais recente. O cliente pode optar por atualizar o MPD a qualquer momento a partir de agora. mpd_location: está presente somente se o new_location_flag está definido e, se assim for, mpd_location fornece um localizador de recursos uniforme para a nova apresentação descrição da mídia. Caso a amplitude de banda usada por atualização constituir um problema, o servidor pode oferecer MPDs para determinados recursos do dispositivo tal que apenas essas partes sejam atualizadas.

Visualização Deslocada no Tempo e PVR de Rede

[000283]Quando for suportada a visualização com time-shift/deslocamento no tempo, pode ocorrer que o tempo ao vivo/live da sessão de dois ou mais MPDs ou cabeçalhos de filme sejam válidos. Neste caso ao atualizar o MPD quando necessário, mas adicionando o mecanismo de validade ou o conceito de período, um MPD válido pode existir para a janela de tempo inteira. Isso significa que o servidor pode garantir que qualquer cabeçalho MPD e de filme são anunciados por qualquer período de tempo que estiver dentro da janela de tempo válida para mudança de tempo de exibição. É o cliente que deve garantir que seu MPD e metadados disponíveis para o atual tempo de apresentação sejam válidos. A migração de uma sessão ao vivo para uma sessão PVR em rede usando apenas pequenas atualizações MPD também pode ser suportada.

Segmentos de Mídia Especiais

[000284]Um problema quando é usado o arquivo de formato de ISO/IEC 14496 12 dentro de um sistema de streaming por solicitação de blocos é o de que, conforme foi acima descrito, pode ser vantajoso armazenar os dados de mídia para uma única versão da apresentação em vários arquivos, organizados em segmentos de tempo consecutivos. Além disso podem ser vantajoso dispor cada arquivo com um ponto de acesso aleatório. Além disso pode ser vantajoso escolher a posição dos pontos de busca durante o processo de codificação de vídeo e segmentar a apresentação em múltiplos arquivos, cada um começando com um ponto de busca baseado na escolha dos pontos de busca que foi feita durante o processo de codificação, em que cada ponto de acesso aleatório pode ou não ser colocado no início de um arquivo, mas em que cada arquivo começa com um ponto de acesso aleatório. Em uma modalidade com as propriedades descritas acima, os metadados de apresentação, ou a descrição de apresentação de mídia, podem conter a duração exata de cada arquivo, onde a duração é tomada por exemplo, para significar a diferente entre o horário de início da mídia de um arquivo de vídeo e a hora de início da mídia vídeo do próximo arquivo. Com base nessas informações nos metadados de apresentação o cliente é capaz de construir um mapeamento entre o cronograma global para a apresentação de mídia e a linha do tempo local para os meios de comunicação dentro de cada arquivo.

[000285]Em outra modalidade, o tamanho dos metadados de apresentação pode ser vantajosamente reduzido, especificando, em vez disso, que todos os arquivos ou segmento têm a mesma duração. No entanto neste caso e onde 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 ao período de duração especificado na descrição de apresentação da mídia, porque um ponto de acesso aleatório pode não existir no ponto em que é exatamente a duração especificada desde o início do arquivo.

[000286] Será agora descrita outra modalidade da invenção para prover uma operação correta do sistema de streaming por requisição de blocos apesar da discrepância acima mencionada. Neste método pode ser provido um elemento dentro de cada arquivo que especifica o mapeamento do cronograma local dos meios de comunicação dentro do arquivo (pelo que deve ser entendido o cronograma a partir do timestamp zero em relação ao qual os timestamps de decodificação e composição das amostras de mídia são especificados de acordo com a ISO/IEC 14496-12) para o cronograma de apresentação global. Essas informações de mapeamento podem incluir um único carimbo de hora/timestamp em hora de apresentação global que corresponde ao carimbo de hora zero na linha do tempo de arquivo local. As informações de mapeamento alternativas podem incluir um valor de deslocamento que especifica a diferença entre o tempo de apresentação global correspondente a zero hora na linha de tempo do arquivo local e o tempo de apresentação global correspondente para o início do arquivo de acordo com as informações fornecidas nos metadados de apresentação.

[000287]Os exemplos para essas caixas/boxes podem incluir o fragmento de faixa “decodificar caixa de tempo” (“tfdt”) ou box de ajuste de fragmento de trilha (“tfad”) juntamente com a caixa de ajuste de mídia de fragmento de trilha (tfma).

Exemplo de Geração de Lista de Segmentos Incluindo Clientes

[000288] Será agora descrito um exemplo de cliente. Ele pode ser usado como um cliente de referência para o servidor para garantir a adequada geração e atualizações do MPD.

[000289]Um cliente de fluxo contínuo/streaming HTTP é guiado pelas informações fornecidas no MPD. Supõe-se que o cliente tem acesso ao MPD que recebeu no tempo T, ou seja, o momento em que foi capaz de receber com êxito um MPD. A determinação da recepção bem sucedida pode incluir o cliente obter um MPD atualizado, ou o cliente verificar que o MPD não foi atualizado desde a recepção com sucesso anterior.

[000290] Será apresentado um exemplo de comportamento de cliente. Para a prestação de um serviço de streaming para o usuário, o cliente primeiro analisa o MPD e cria uma lista de segmentos acessíveis para cada representação para a hora local do cliente em uma hora atual do sistema, levando em conta os procedimentos de geração de lista de segmentos conforme detalhado abaixo, possivelmente usando listas de reprodução ou usando as regras de construção de URL. Em seguida, o cliente seleciona uma ou múltiplas representações baseado em informações nos atributos de representação e outras informações, por exemplo, recursos de cliente e amplitude de banda disponíveis. Dependendo do agrupamento, as representações podem ser apresentadas de forma autônoma ou conjuntamente com outras representações.

[000291]Para cada representação, o cliente adquire os metadados binários, como o cabeçalho moov para a representação, caso presente, e os segmentos de mídia das representações selecionados. O cliente acessa o conteúdo de mídia requerendo segmentos ou intervalos de bytes de segmentos, possivelmente usando a lista de segmentos. O cliente pode inicialmente acumular em buffer as mídia antes de iniciar a apresentação e, depois que a apresentação for iniciada, o cliente continua a consumir o conteúdo de mídia solicitando continuamente segmentos ou partes de segmentos tendo em conta os procedimentos de atualização de MPD.

[000292]O cliente pode alternar/comutar representações tendo em conta as informações atualizadas de MPD ou informações atualizadas de seu ambiente, por exemplo mudança da amplitude de banda disponível. Com qualquer pedido de um segmento de mídia que contém um ponto de acesso aleatório, o cliente pode alternar para uma representação diferente. Quando seguir em frente, isto é, a hora do sistema atual (referido como o “tempo NOW” para representar o tempo relativo para a apresentação), o cliente consome os segmentos acessíveis. Com cada avanço no tempo NOW, o cliente possivelmente expande a lista de segmentos acessíveis para cada representação de acordo com os procedimentos especificados neste documento.

[000293]Caso o final da apresentação de mídia não for ainda alcançado e caso o tempo de reprodução corrente se aproxime de um limite em que o cliente prevê o esgotamento dos mídia descritos no MPD para o consumo da representação, o cliente pode solicitar uma atualização de MPD, com uma nova recepção de tempo de busca t. Uma vez recebido, o cliente, em seguida, leva em consideração o MPD possivelmente atualizado e o novo tempo t na geração de listas de segmento acessíveis. A Figura 29 ilustra um procedimento para serviços live/ao vivo em momentos diferentes no cliente.

Geração de Lista de Segmentos Acessíveis

[000294]Vamos presumir que o cliente de streaming HTTP tem acesso a um MPD e pode desejar gerar uma lista de segmentos acessíveis para uma hora de relógio NOW. O cliente está sincronizado a uma referência de tempo global com certa precisão, mas vantajosamente nenhuma sincronização direta para o servidor de fluxo contínuo/streaming de HTTP é necessária.

[000295]A lista de segmentos acessíveis para cada representação é de preferência definida na forma de uma lista de pares de instantes de início de segmento e localizadores de segmentos, em que a hora de início do segmento pode ser definida como sendo relativa ao início da representação sem perda de generalidade. O início da representação pode ser alinhado com o início de um período ou se este conceito é aplicado. Caso contrário, o início de representação pode ser no início da apresentação de mídia.

[000296]O cliente usa as regras de construção de URL e o timing tal como, por exemplo, definido neste documento. Depois de obter uma lista de segmentos descritos, esta lista é adicionalmente restringida aos acessíveis, os quais podem ser um subconjunto dos segmentos da apresentação completa de mídia. A construção é regida pelo valor atual do relógio na hora NOW do cliente. De um modo geral, os segmentos só estarão disponíveis para qualquer momento NOW dentro de um conjunto de horas/intervalos de disponibilidade. Para os tempos fora de tal janela, nenhum segmento está disponível. Além disso, para serviços live/ao vivo, presume-se que a checktime em algum instante fornece informações sobre quanto para o futuro a mídia é descrita. O checktime é definido no eixo do tempo da mídia documentada em MPD; quando o tempo de reprodução do cliente atinge checktime, ele vantajosamente solicita um novo MPD.

[000297]Quando o tempo de reprodução do cliente atinge checktime, ele vantajosamente solicita um novo MPD.

[000298]Em seguida, a lista de segmentos é adicionalmente restrita pelo checktime junto com o atributo MPD TimeShiftBufferDepth de tal modo que apenas os segmentos de mídia disponíveis são aqueles para os quais a soma do tempo de início do segmento de mídia e o início da representação se inserem no intervalo entre NOW menos timeShiftBufferDepth menos a duração do último segmento descrito e o menor valor dentre checktime ou NOW.

Blocos Escalonáveis

[000299]Algumas vezes a amplitude de banda disponível se reduz tanto que o bloco ou blocos atualmente sendo recebidos em um receptor se tornam pouco prováveis de ser completamente recebidos em tempo para serem reproduzidos sem interromper a apresentação. O receptor pode detectar tais situações com antecedência. Como exemplo, o receptor pode determinar que ele está recebendo blocos que codificam 5 unidades de mídia a cada 6 unidades de tempo e que possui um buffer de acumulação de 4 unidades de mídia, de forma que o receptor pode esperar ter que parar ou pausar a apresentação cerca de 24 unidades de tempo mais tarde. Com antecedência suficiente, o receptor pode reagir a tal situação, por exemplo, abandonando o fluxo atual de blocos e iniciar a solicitação de um bloco ou blocos de uma representação diferente do conteúdo, tal como um que use menos amplitude/largura de banda por unidade de tempo de playout/reprodução. Como exemplo, caso o receptor se comute para uma representação onde blocos codificados por pelo menos 20% mais tempo de vídeo para os blocos de mesmo tamanho, o receptor poderia ser capaz de eliminar a necessidade de parar até que melhorasse a situação de largura de banda.

[000300]No entanto, pode ser um desperdício o fato de o receptor descartar inteiramente os dados já recebidos da representação da representação abandonada. Em uma modalidade do sistema de streaming de blocos aqui descrito, os dados dentro de cada bloco podem ser codificados e organizados de tal forma que determinados prefixos dos dados dentro do bloco podem ser usados para continuar a apresentação sem o restante do bloco ter sido recebido. Como exemplo, podem ser utilizadas as técnicas bem conhecidas de codificação de vídeo escalonável. Os exemplos de tais métodos de codificação de vídeo incluem a codificação de vídeo avançada (AVC) H.264 - codificação de vídeo escalonável (SVC), ou o escalonamento temporal da norma H.264 Advanced Video Coding (AVC). Vantajosamente, esse método permite que a apresentação continue com base na parte de um bloco que tenha sido recebido, mesmo quando a recepção de um bloco ou blocos possa ter sido abandonada, por exemplo devido a mudanças na largura de banda disponível. Outra vantagem é a de que um arquivo de dados único pode ser usado como a fonte para várias representações diferentes do conteúdo. Isso é possível, por exemplo, fazendo uso de requisições do tipo HTTP partial GET que selecione o subconjunto de um bloco correspondente a representação necessária.

[000301]Uma melhoria detalhada neste documento consiste de um segmento ampliado, um mapa de segmento escalonável. O mapa de segmento escalonável contém as localizações das diferentes camadas no segmento de tal modo que o cliente possa acessar devidamente as partes dos segmentos e extrair as camadas. Em outra modalidade, os dados de mídia no segmento são ordenados de tal forma que a qualidade do segmento aumenta durante o download gradual dos dados desde o início do segmento. Em outra modalidade, o aumento gradual da qualidade é aplicado para cada bloco ou o fragmento contido no segmento, tal que as solicitações de fragmento podem ser feitas para solucionar a abordagem escalonável.

[000302]A Figura 12 ilustra um aspecto de blocos escalonáveis. Nesta figura, um transmissor 1200 emite metadados 1202 na camada escalonável 1 (1204), camada escalonável 2 (1206) e camada escalonável 3 (1208), com a última sendo adiada. Um receptor 1210 em seguida pode utilizar metadados 1202, a camada escalonável 1 (1204) e a camada escalonável 2 (1206) para reproduzir a apresentação mídia 1212.

Camadas Independentes de Escalonamento

[000303]Como foi explanado acima, é indesejável que um sistema de streaming de requisição de blocos seja obrigado a parar quando o receptor não é capaz de receber os blocos requisitados de uma representação específica dos dados de mídia solicitados em tempo para sua reprodução, o que muitas vezes cria uma experiência de usuário ruim. As paradas podem ser evitadas, reduzidas ou atenuadas, restringindo-se uma taxa de dados das representações de modo a ser muito menor do que a largura de banda disponível, para que se torne muito improvável que qualquer parte determinada da apresentação não seja recebida a tempo, mas esta estratégia tem a desvantagem de que a qualidade da mídia é necessariamente muito menor do que poderia ser a princípio suportada pela largura de banda disponível. Uma apresentação de qualidade mais baixa do que aquela que é possível também pode ser interpretada como uma experiência de usuário ruim. Assim, o projetista de um sistema de streaming para solicitação de blocos é confrontado com uma escolha no projeto dos procedimentos de cliente, programação do cliente ou da configuração do hardware, a ou solicitar uma versão de conteúdo que tem uma taxa de dados muito mais baixa do que a largura de banda disponível, caso este em que o usuário pode sofrer com a qualidade da mídia pobre, ou solicitar uma versão de conteúdo que tem uma taxa de dados perto de largura de banda disponível, caso em que o usuário pode sofrer uma alta probabilidade de pausas durante a apresentação a medida que se altera a largura de banda disponível.

[000304]Para lidar com tais situações, o sistema de streaming por solicitação de blocos aqui descrito pode estar configurado para manipular várias camadas de escalonamento de forma independente, tal que um receptor possa fazer solicitações em camadas e um transmissor pode responder às solicitações de camadas.

[000305]Em tais modalidades, os dados de mídia codificados para cada bloco podem ser particionados em vários peças separadas/desconexas, referidas neste documento como “camadas”, tal que uma combinação de camadas compreende o total dos dados de mídia de um bloco e tal que um cliente que tenha recebido certos subconjuntos das camadas possa executar a decodificação e apresentação de uma representação do conteúdo. Nesta abordagem, a ordenação dos dados no fluxo é tal que intervalos contíguos aumentam a qualidade e os metadados refletem isto.

[000306]Um exemplo de uma técnica que pode ser usada para gerar camadas com a propriedade acima é a técnica de codificação de vídeo escalonável, por exemplo tal como descrito nas normas ITU T H.264/SVC. Outro exemplo de uma técnica que pode ser usada para gerar camadas com a propriedade acima é a técnica de camadas de escalonamento temporal prevista na norma ITU T h.264/AVC.

[000307]Em tais modalidades, metadados podem ser fornecidos no MPD ou no próprio segmento, o que possibilita a construção de requisições de camadas individuais de qualquer bloco e/ou combinações de camadas determinados e/ou uma determinada camada de múltiplos blocos e/ou uma combinação de camadas de múltiplos blocos. Como exemplo, as camadas que incluem um bloco podem estar armazenadas em um único arquivo e metadados poderiam ser fornecidos especificando os intervalos de bytes no arquivo correspondente às camadas individuais.

[000308]Um protocolo para download de arquivos capaz de especificar intervalos de bytes, por exemplo o HTTP 1.1, pode ser usado para solicitar camadas individuais ou múltiplas camadas. Além disso, como ficará claro para os técnicos na área ao ler a presente descrição, as técnicas descritas acima referentes à construção, requisição e download de blocos de tamanho variável e combinações variáveis de blocos podem ser aplicadas também neste contexto.

Combinações

[000309] Serão agora descritas algumas modalidades que podem ser vantajosamente empregadas por um cliente de streaming por solicitação de blocos para obter uma melhoria na experiência do usuário e/ou uma redução dos requisitos de capacidade da infraestrutura servidora em comparação às técnicas existentes pelo uso de dados de mídia particionados em camadas conforme foi descrito acima.

[000310]Em uma primeira modalidade, as técnicas conhecidas de um sistema de streaming por solicitação de blocos podem ser aplicadas com a modificação de que versões diferentes do conteúdo são em alguns casos, substituídas por diferentes combinações das camadas. Isto é, quando um sistema existente pode fornecer duas representações distintas do conteúdo no sistema aperfeiçoado aqui descrito em duas camadas, em que uma representação do conteúdo do sistema existente é semelhante em termos de taxa de bits, a qualidade, e possivelmente outras medidas, para a primeira camada no sistema aprimorado e a segunda representação do conteúdo do sistema existente é semelhante em taxa de bits, qualidade e possivelmente outras medidas para a combinação de duas camadas do sistema avançado. Como resultado a capacidade de armazenamento necessária dentro do sistema avançado é reduzida em relação àquela exigida no sistema existente. Além disso, considerando que os clientes do sistema existente podem emitir solicitações para blocos de representação de uma ou outra representação, os clientes do sistema avançado podem emitir solicitações para a primeira ou ambas camadas de um bloco. Como resultado, a experiência do usuário nos dois sistemas é semelhante. Além disso, um armazenamento em cache aprimorado é fornecido, dado que mesmo para qualidades diferentes são usados segmentos comuns que são armazenadas em cache com maior probabilidade.

[000311]Em uma segunda modalidade, um cliente em um sistema de streaming por solicitação de blocos ampliado que emprega o método de camadas agora descrito pode manter um buffer de dados separado para cada uma das várias camadas da codificação de mídia. Como ficará claro para os técnicos na área de gerenciamento de dados em dispositivos cliente, esses buffers “separados” podem ser implementados por alocação de regiões da memória física ou logicamente separadas para os buffers separados, ou por outras técnicas em que os dados em buffer são armazenados em uma única ou em múltiplas regiões de memória e a separação dos dados de diferentes camadas é conseguida logicamente através do uso de estruturas de dados que contêm referências para os locais de armazenamento de dados provenientes das camadas separadas e, assim, pela expressão “buffers separados” deve ser entendido como incluindo qualquer método no qual os dados das camadas distintas podem ser identificados separadamente. O cliente emite requisições de camadas individuais de cada bloco com base na ocupação de cada buffer por exemplo, as camadas podem ser pedidas em uma ordem de prioridade tal que uma solicitação de dados de uma camada não pode ser concedida se a ocupação de qualquer buffer para uma camada inferior na ordem de prioridade estiver abaixo de um limite para tal camada inferior. Neste método é dada prioridade para recepção de dados de camadas inferiores na ordem de prioridade, tal que se a largura de banda disponível cai abaixo do exigido para também receber camadas superiores na ordem de prioridade, então somente as camadas inferiores são solicitadas. Além disso, os limites associados com as diferentes camadas podem ser diferentes, tal que, por exemplo, as camadas inferiores têm limiares mais elevados. No caso em que a largura de banda disponível é alterada tal que os dados de uma camada superior não podem ser recebidos antes do momento de reprodução/playout do bloco, os dados para camadas inferiores deverão necessariamente já ter sido recebidos, podendo assim continuar a apresentação com as camadas inferiores por si só. Os limites para a ocupação de buffers podem ser definidos em termos de bytes de dados, duração de reprodução dos dados contidos no buffer, número de blocos ou qualquer outra medida adequada.

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

[000313]Em uma quarta modalidade os métodos das primeira, segunda e/ou terceira modalidades podem ser combinados com a modalidade em que múltiplas representações independentes do conteúdo são fornecidas de tal modo que, por exemplo, pelo menos uma das representações independentes compreende várias camadas para que as técnicas das primeira, segunda e/ou terceira modalidades sejam aplicadas.

Gerenciador de Buffer Avançado

[000314]Em combinação com o monitor de buffer 126 (ver Figura 2), um gerenciador de buffer avançado pode ser usado para otimizar um buffer na ponta do cliente. Os sistemas de fluxo contínuo de solicitação de blocos deseja garantir que a reprodução de mídia pode se iniciar rapidamente e continuar sem problemas, assegurando simultaneamente a qualidade da mídia máxima para o dispositivo de usuário ou de destino. Isso pode exigir que o cliente solicite blocos que possuem a mais alta qualidade de mídia, mas que também possam ser iniciados rapidamente e recebidos a tempo e a seguir serem reproduzidos sem forçar uma pausa na apresentação.

[000315]Nas modalidades que utilizam o gerenciador de buffer avançado, o gerenciador determina quais blocos de dados devem ser requisitados e quando fazer tais solicitações. Um gerenciador de buffer avançado pode, por exemplo, receber um conjunto de metadados do conteúdo a ser apresentado, estes metadados, incluindo uma lista de representações disponíveis para o conteúdo e os metadados para cada representação. Os metadados para uma representação podem incluir informações sobre a taxa de dados e outros parâmetros, tais como parâmetros de vídeo, áudio ou outros codecs e parâmetros de codec, resolução de vídeo, complexidade de decodificação, idioma do áudio e quaisquer outros parâmetros que podem afetar a escolha da representação no cliente.

[000316]Os metadados para uma representação também podem incluir identificadores para os blocos em que a representação foi segmentada, esses identificadores fornecendo as informações necessárias para o cliente solicitar um bloco. Como exemplo, quando o protocolo de solicitação for o HTTP, o identificador pode ser um URL de HTTP, possivelmente com informações adicionais identificando um intervalo de bytes ou intervalo de tempo dentro do arquivo identificado pelo URL, tal intervalo de bytes ou tempo identificando o bloco específico dentro do arquivo identificado pelo URL.

[000317]Em uma implementação específica, o gerenciador de buffer avançado determina quando um receptor faz um pedido de novos blocos e pode, ele próprio, lidar com o envio das solicitações. Em um novo aspecto, o gerenciador de buffer avançado efetua as solicitações de novos blocos de acordo com o valor de uma relação de equilíbrio que equilibra o uso de muita largura de banda e o esgotamento dos mídia durante uma reprodução.

[000318]As informações recebidas pelo monitor de buffer 126 provenientes do buffer de blocos 125 podem incluir indicações de cada evento em que dados de mídia são recebidos, quanto foram recebidos, quando o playout de dados de mídia foi iniciado ou interrompido e a velocidade da reprodução de mídia. Com base nessas informações, o monitor de buffer 126 pode calcular uma variável que representa um tamanho de buffer atual, Bcurrent. Nestes exemplos, Bcurrent representa a quantidade de mídia contidos em um cliente ou outros buffers de dispositivo, podendo ser medida em unidades de tempo para que Bcurrent represente a quantidade de tempo necessária para reproduzir toda a mídia representada pelos blocos ou blocos parciais armazenados em buffer ou buffers caso nenhum bloco adicional, ou blocos parciais, fossem recebidos. Dessa forma, Bcurrent representa a “duração de reprodução”, na velocidade normal de reprodução, dos dados de mídia disponíveis no cliente, mas ainda não reproduzidos.

[000319]A medida que passa o tempo, o valor de Bcurrent diminuirá a medida que a mídia é reproduzida e pode aumentar a cada vez que um novo bloco é recebido. Note-se que, para efeitos da presente descrição, supõem-se que um bloco é recebido quando os todos os dados do bloco estejam disponíveis no requisitador de blocos 124, mas outras medidas podem ser usadas por exemplo levando em conta a recepção de blocos parciais. Na prática, a recepção de um bloco pode ocorrer durante um período de tempo.

[000320]A Figura 13 ilustra uma variação do valor de Bcurrent ao longo do tempo a medida que a mídia é reproduzida e blocos são recebidos. Tal como ilustrado na Figura 13, o valor de Bcurrent é zero para tempos anteriores a t0, indicando que nenhum dado foi recebido. Em t0, o primeiro bloco é recebido e o valor de Bcurrent aumenta de modo a igualar a duração de playout/reprodução do bloco recebido. Neste momento, a reprodução ainda não começou e então o valor de Bcurrent permanece constante até o instante t1, em que um segundo bloco chega e aumenta Bcurrent pelo tamanho deste segundo bloco. Neste momento a reprodução se inicia e o valor de Bcurrent começa a diminuir de forma linear, até o tempo t2, na instante em que um terceiro bloco chega.

[000321]A progressão da Bcurrent continua desta forma em “dente de serra”, aumentando em degraus a cada vez que um bloco é recebido (nos instantes t2, t3, t4, t5 e t6) e diminuindo suavemente a medida que os dados são reproduzidos. Note-se que neste exemplo a reprodução prossegue à taxa normal de playout do conteúdo e portanto a inclinação da curva entre a recepção de blocos é exatamente 1, significando que um segundo de dados de mídia é reproduzido para cada 1 segundo do tempo real que transcorre. Com a mídia baseada em quadros sendo reproduzida em um determinado número de quadros por segundo, por exemplo, 24 quadros por segundo, a inclinação de -1 irá ser aproximada por funções de pequeno passo que indicam a reprodução de cada quadro individual dos dados, por exemplo etapas de 1/24 de segundo quando cada quadro é reproduzido.

[000322]A Figura 14 mostra outro exemplo da evolução de Bcurrent ao longo do tempo. Nesse exemplo, o primeiro bloco chega em t0 e a reprodução/playout começa imediatamente. A chegada de blocos e a reprodução/playout continuam até o momento t3, no qual o valor de Bcurrent chega a zero. Quando isso acontece, não há mais dados de mídia disponíveis para reprodução, forçando uma pausa na apresentação de mídia. No tempo/instante t4, um quarto bloco é recebido e a reprodução pode recomeçar. Este exemplo mostra, portanto, um caso onde a recepção do quarto bloco foi mais tarde do que o desejado, resultando em uma pausa na reprodução e, portanto, uma experiência de usuário ruim. Assim, é um objetivo do gerenciador de buffer avançado e outros recursos reduzir a probabilidade deste evento, mantendo simultaneamente mídia de alta qualidade.

[000323]O monitor de buffer 126 pode também calcular outra medida, Bratio(t), que é a relação entre a mídia recebida em um determinado período de tempo e a duração do período de tempo. Mais especificamente, Bratio(t) é igual a Treceived/(Tnow-t), em que Treceived é a quantidade de mídia (medida pelo seu tempo de reprodução) recebidas no período de tempo de t, algum tempo antes que o tempo atual, até o momento atual, Tnow.

[000324]Bratio(t) pode ser usado para medir a taxa de mudança de Bcurrent. Bratio(t) = 0 é o caso onde nenhum dado foi recebido desde o tempo t; Bcurrent será reduzida por (Tnow-t) desde então, assumindo que a mídia está sendo reproduzida. Bratio(t) = 1 é o caso em que de mídia é recebida na mesma quantidade que está sendo reproduzida, para o tempo (Tnow-t); Bcurrent terá o mesmo valor no tempo Tnow que o tempo t. Bratio(t) > 1 é o caso onde mais dados foram recebidos do que o necessário para reproduzir no tempo (Tnow-t); Bcurrent terá aumentado do tempo t até o tempo Tnow.

[000325]O monitor de buffer 126 calcula também um valor State, que pode assumir um certo número de valores. O monitor de buffer 126 está também equipado com uma função, NewState (Bcurrent, Bratio), que, dado o valor atual de Bcurrent e valores de Bratio para t < Tnow, fornece um novo valor de State como saída. Sempre que Bcurrent e Bratio levam essa função a retornar um valor diferente do valor atual de State, o novo valor é atribuído a State e este novo valor de State indicado para o bloco seletor 123.

[000326]A função NewState pode ser avaliada com referência ao espaço de todos os valores possíveis 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 valores de Bcurrent para valores de TX, ou pode depender do valor anterior de State. O monitor de buffer 126 recebe uma ou mais partições deste espaço, onde cada particionamento compreende conjuntos de regiões desconexas, cada região estando anotada com um valor de State. A avaliação da função NewState então compreende a operação de identificar um particionamento e determinar a região em que o par (Bcurrent, Bratio(Tnow-Tx)) reside. O valor de retorno é então a anotação associada com essa região. Em um caso simples, um único particionamento é fornecido. Em um caso mais complexo, o particionamento pode depender do par (Bcurrent, Bratio(Tnow Tx)) na época anterior da avaliação da função NewState ou em outros fatores.

[000327]Em uma modalidade específica, o particionamento descrito acima pode basear-se em uma tabela de configuração que contém um número de valores de limite para Bcurrent e um número de valores de limite para Bratio. Especificamente, sejam os valores-limite para a Bcurrent Bthresh(0) = 0, Bthresh(l), ..., Bthresh(n1), Bthresh(n1+1) = ~, onde n1 é o número de valores de limite diferentes de zero para Bcurrent. Sejam os valores-limite para Bratio Br-thresh(0) = 0, thresh(l)Br, ..., Brthresh(n2), Brthresh(n2+1) = “, onde n2 é o número de valores de limiar para Bratio. Esses valores de limiar definem um particionamento compreendendo uma grade de (nl + 1) (n2 + 1) de células, onde a ia célula da linha jacorresponde à região na qual Bthresh(i 1) <Bcurrent < Bthresh(i) e r-Bthresh(j- 1) <Bratio < Br-thresh(j) . Cada célula da grade acima descrita é anotada com um valor de State, como por ser associado com valores particulares armazenados na memória e a função NewState a seguir retorna o valor de State associado à célula indicada pelos valores Bcurrent e Bratio(Tnow-Tx).

[000328]Em outra modalidade, um valor de histerese pode ser associado a cada valor de limiar. Neste método avançado, a avaliação da função newState pode basear-se em um particionamento temporário construído usando temporariamente um conjunto temporariamente modificado de valores de limite, como se segue. Para cada valor de limite de Bcurrent que for menor do que o intervalo de Bcurrent correspondente à célula escolhida na última avaliação do NewState, o valor de limite é reduzido, subtraindo o valor limiar de histerese associado com esse limite. Para cada valor de limite de Bcurrent que for maior do que o intervalo de Bcurrent correspondente à célula escolhida na última avaliação do NewState, o valor de limite é aumentado, adicionando o valor limiar de histerese associado com esse limite. Para cada valor de limite de Bratio que for menor do que o intervalo de Bratio correspondente à célula escolhida na última avaliação do NewState, o valor de limite é reduzido, subtraindo o valor limiar de histerese associado com esse limite. Para cada valor de limite de Bratio que for maior do que o intervalo de Bratio correspondente à célula escolhida na última avaliação do NewState, o valor de limite é aumentado, adicionando o valor limiar de histerese associado com esse limite. Os valores de limiar modificados são usados para avaliar o valor de NewState e, em seguida, os valores de limiar são retornados para seus valores originais.

[000329]A descrição acima é ilustrativa do processo básico. Como será claro para os técnicos na área de programação em tempo real após a leitura desta descrição, implementações eficientes são possíveis. Por exemplo, em cada vez que nova informação é fornecida para o monitor de buffer 126, é possível calcular o tempo futuro em que NewState irá passar para um novo valor se, por exemplo não existem dados adicionais para recebimento pelos blocos. Um temporizador/timer é então definido para este tempo e na ausência de outras entradas este temporizador expira o que irá fazer com que o novo valor de state a ser enviado para o seletor de blocos 123. Como resultado, os cálculos só necessitam de ser realizados quando a nova informação é fornecida para o monitor de buffer de 126 ou quando um temporizador expira, em vez de continuamente.

[000330]Os valores adequados de State poderiam ser "Low" (baixo), "estável"e "Full" (cheio). Um exemplo de um conjunto adequado de valores de limiar e na grade de célula resultante é mostrado na Figura 15.

[000331]Na Figura 15, os limiares de Bcurrent são mostrados no eixo horizontal em milissegundos, com valores de histerese mostradas abaixo como "+ valor /". Limiares Bratio são mostrados no eixo vertical em permille (isto é, multiplicado por 1000) com valores de histerese mostradas abaixo como "+ valor /". Valores de state são anotadas nas células da grade como "L", "S" e "F" para "Low", "estável"e "Full", respectivamente.

[000332]O seletor de blocos 123 recebe notificações do solicitador de blocos 124 sempre que houver uma oportunidade de pedir um novo bloco. Como descrito acima, o seletor de blocos 123 é fornecido com os dados como a pluralidade de blocos disponíveis e metadados para esses blocos, incluindo por exemplo, informações sobre a taxa de suportes de dados de cada bloco.

[000333]As informações sobre a taxa de suportes de dados de um bloco pode compreender o real meios taxa de dados do bloco específico (isto é, o tamanho do bloco em bytes dividido pelo tempo de reprodução em segundos), a média meios taxa de dados de a representação à qual o bloco pertence ou uma medida da largura de banda disponível necessário, numa base sustentável, a desempenhar a representação a que pertence o bloco sem pausas, ou uma combinação dos anteriores.

[000334]O seletor de blocos 123 seleciona blocos com base no valor indicado pelo último valor State indicado pelo monitor de buffer 126. Quando este valor State é "estável", o seletor de blocos 123 seleciona um bloco da mesma representação que o bloco anterior selecionado. O bloco selecionado é o primeiro bloco (em ordem de reprodução/playout) contendo suportes de dados para um período de tempo na apresentação para os quais não tenham sido requeridos suportes de dados previamente.

[000335]Quando o valor de State é "Low", o seletor de blocos 123 seleciona um bloco a partir de uma representação com uma menor taxa de dados de mídia do que o bloco selecionado anteriormente. Uma série de fatores podem influenciar a escolha exata da representação no presente caso. Por exemplo, o seletor de blocos 123 pode receber uma indicação da taxa total de dados de entrada e pode escolher uma representação com uma taxa de suportes de dados que é inferior a esse valor.

[000336]Quando o valor do State é "Full", o seletor de blocos 123 seleciona um bloco a partir de uma representação com uma maior taxa de dados de mídia do que o bloco selecionado anteriormente. Uma série de fatores podem influenciar a escolha exata da representação no presente caso. Por exemplo, o seletor de blocos 123 pode ser provido com uma indicação da taxa total de dados de entrada e pode escolher uma representação com uma taxa de suportes de dados que não é maior do que aquele valor.

[000337]Uma série de fatores adicionais podem ainda influenciar o funcionamento do seletor de blocos 123. Em particular, a freqüência com que a taxa de suportes de dados do bloco selecionado é aumentada pode ser limitado, mesmo se buffer de monitor 126 continua para indicar o state "total". Além disso, é possível que o seletor de blocos 123 receba uma indicação de state "Full", mas não existem blocos de maior taxa de dados de mídia disponíveis (por exemplo, porque o último bloco selecionado já estava disponível para a mídia mais alta taxa de dados). Neste caso, o seletor de blocos 123 pode atrasar a seleção do bloco seguinte por um tempo escolhido de tal modo que a quantidade total de dados meios tamponados em buffer de bloqueio 125 é delimitada acima.

[000338]Outros fatores podem influenciar o conjunto de blocos que são considerados durante o processo de seleção. Por exemplo, os blocos disponíveis podem ser limitados àqueles a partir de representações cuja resolução de codificação cai dentro de uma gama específica fornecida para o seletor de blocos 123.

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

[000340]A modalidade acima descrita traz uma vantagem substancial em que a utilização do valor Bratio na avaliação da função NewState dentro do monitor de buffer 126 permite um aumento mais rápido 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 em buffer pode ser acumulada antes que o sistema é capaz de selecionar blocos com maior taxa de dados de mídia e, conseqüentemente, uma maior qualidade. No entanto, quando o valor Bratio é grande, isto indica que a largura de banda disponível é muito mais elevada do que a taxa de suporte de dados dos blocos receberam previamente e que, mesmo com relativamente poucos dados tamponadas (isto é, baixo valor para Bcurrent), ele continua a ser seguro para solicitar blocos de taxa mais elevada de suporte de dados e, portanto, a qualidade mais elevada. Igualmente, se o valor Bratio é baixa (<1, por exemplo), isso indica que a largura de banda disponível caiu abaixo da taxa de suportes de dados dos blocos previamente solicitados e, assim, mesmo se Bcurrent é elevada, o sistema irá mudar para um meio mais baixos a taxa de dados e, conseqüentemente, uma menor qualidade, por exemplo para evitar atingir o ponto onde Bcurrent = 0 e o playout das baias meios de comunicação. Esse comportamento melhor pode ser especialmente importante em ambientes onde as condições da rede e, assim, velocidades de entrega podem variar de forma rápida e dinâmica, por exemplo, usuários de streaming para dispositivos móveis.

[000341]Outra vantagem é conferida pelo uso de dados de configuração para especificar o particionamento do espaço de valores de (Bcurrent, Bratio). Tais dados de configuração pode ser fornecidos para o monitor de buffer 126 como parte dos metadados da apresentação ou por outros meios dinâmicos. Uma vez que, em implementações práticas, o comportamento das conexões de rede do usuário pode ser altamente variável entre os usuários e ao longo do tempo para um único usuário, pode ser difícil de prever um particionamento que vai funcionar bem para todos os usuários. A possibilidade de fornecer informações de configuração, permite aos usuários de forma dinâmica permite boas configurações serem desenvolvidas ao longo do tempo de acordo com a experiência acumulada.

Dimensionamento Variável de Requisições

[000342]Uma alta freqüência de pedidos pode ser necessária se cada pedido é para um único bloco e se cada bloco codifica para um segmento de mídia curto. Se os blocos de mídia são curtos, a reprodução de vídeo está se movendo de bloco em bloco rapidamente, o que oferece oportunidades mais freqüentes para o receptor para ajustar ou alterar sua taxa de dados selecionado, alterando a representação, melhorando a probabilidade de que o playout pode continuar sem parar. No entanto, uma desvantagem para uma alta freqüência de requisições é que elas podem não ser sustentáveis em determinadas redes em que a largura de banda disponível é limitada no cliente pelo servidor de rede, por exemplo, em redes sem fio WAN, tais como 3G e 4G wireless WANs, onde a capacidade da conexão de dados do cliente para a rede é limitada ou pode tornar-se limitada por períodos longos ou curtos de tempo devido a alterações nas condições de rádio comunicação.

[000343]A freqüência elevada de pedidos/requisições também implica uma elevada carga sobre a infra-estrutura que serve, o que traz custos associados em termos de requisitos de capacidade. Assim, seria desejável ter alguns dos benefícios de uma freqüência elevada de pedidos sem todas as desvantagens.

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

[000345]Uma configuração básica que pode ser acionada pela decisão de solicitar um bloco único (ou um bloco parcial) ou para pedir vários blocos consecutivos é ter a configuração baseando a decisão sobre se ou não os blocos solicitados são susceptíveis de serem reproduzidos ou não. Como exemplo, se é provável que não haverá a necessidade de mudar para uma outra representação em breve, então é melhor para o cliente para fazer pedidos de blocos individuais, isto é, pequenas quantidades de dados multimídia. Uma razão para isto é que, se um pedido de blocos múltiplos é feita quando uma comutação para uma outra representação pode ser iminente é que a comutação pode ser feita antes dos últimos poucos blocos do pedido serem reproduzidos. Dessa forma, o download desses últimos blocos pode atrasar a entrega de dados de mídia da representação para a qual a troca é feita, o que poderia causar paradas no playout de mídia.

[000346]No entanto, os pedidos de blocos simples resultam em uma maior freqüência de requisições. Por outro lado, se é improvável que haverá uma necessidade de mudar para uma outra representação em breve, então pode ser preferido fazer pedidos de blocos múltiplos, dado que todos estes blocos são susceptíveis de serem reproduzidos, e isto resulta em uma menor freqüência de pedidos, o que pode reduzir substancialmente a sobrecarga de pedidos, especialmente se é claro que não haverá alteração de representação iminente.

[000347]Em sistemas convencionais de agregação de blocos, a quantidade solicitada em cada pedido não é ajustada dinamicamente, ou seja, tipicamente cada pedido é para um arquivo inteiro, ou cada pedido é de aproximadamente a mesma quantidade do arquivo de uma representação (por vezes medido em tempo, por vezes em bytes). Assim, se todos os pedidos são menores, então a sobrecarga de pedidos é elevada, ao passo que se todos os pedidos são maiores, então isso aumenta as chances de eventos da parada de mídia e/ou prestação de um serviço de baixa qualidade de reprodução da mídia caso as representações de baixa qualidade forem escolhidas para evitar ter que mudar rapidamente de representações a medida que as condições da rede variam.

[000348]Um exemplo de uma condição que, quando encontrada, pode causar pedidos subseqüentes para fazer referência a vários blocos, é um limiar no tamanho do buffer, Bcurrent. Se Bcurrent está abaixo do limiar, então cada pedido emitido referencia um único bloco. Se Bcurrent é maior do que ou igual ao limiar, cada pedido emitido referencia blocos múltiplos. Se um pedido for emitido com referências a blocos múltiplos, o número de blocos solicitados em cada pedido único pode ser determinado de uma das várias maneiras possíveis. Por exemplo, o número pode ser constante, por exemplo, dois. Alternativamente, o número de blocos solicitados num único pedido pode ser dependente do State do buffer e em particular em Bcurrent. Por exemplo, um número de limiares podem ser definidos, com o número de blocos solicitados num único pedido sendo derivado do mais alto dos limiares múltiplos que é menor do que Bcurrent.

[000349]Outro exemplo de uma condição que, quando atendida, pode causar solicitações para fazer referência a vários blocos, é a variável de valor State acima descrita. Por exemplo, quando o State é "estável"ou "Full", em seguida, as solicitações podem ser emitidas por vários blocos, mas, quando o State é "Low", então todos os pedidos podem ser para um bloco.

[000350]Outra modalidade está ilustrada na Figura 16. Nesta modalidade, quando o pedido seguinte deve ser emitido (determinado na etapa 1300), o valor do state atual e Bcurrent é usado para determinar o tamanho do pedido seguinte. Se o valor atual State é "Low" ou o valor do state atual é "Full" e a representação atual não é a mais alta disponível (determinado na etapa 1310, a resposta é "Sim"), então o próximo pedido é escolhido para ser curto, por exemplo, apenas para o bloco seguinte (bloco determinado e pedido feito na etapa 1320). A lógica por trás deste é que estas são as condições em que é provável que, muito breve, haverá uma mudança de representações. Se o valor atual State é "estável"ou o valor do state atual é "Full" e a representação atual é o mais alto disponível (determinado na etapa 1310, a resposta é "Não"), então a duração dos blocos consecutivos solicitados na próxima pedido é escolhida para ser proporcional a uma fração de α Bcurrent para alguns fixos α < 1 (blocos determinadas na etapa 1330, o pedido feito na etapa 1340), por exemplo, para α = 0,4, se Bcurrent = 5 segundos, então o pedido seguinte pôde ser de cerca de 2 segundos de blocos, enquanto que se Bcurrent = 10 segundos, então o próximo pedido pode ser para cerca de 4 segundos de blocos. Uma razão para isto é que, nestas condições, pode ser improvável que uma mudança para uma nova representação será feita para uma quantidade de tempo que é proporcional a Bcurrent.

Operação Flexível em Pipeline

[000351]Os sistemas de streaming de bloco podem usar um protocolo de solicitação de arquivo que tem um protocolo de transporte específico subjacente, por exemplo TCP/IP. O início de um TCP/IP ou outro protocolo de ligação de transporte, pode demorar um tempo considerável para alcançar a utilização da largura de banda total disponível. Isso pode resultar em uma “pena de conexão de inicialização” cada vez que uma nova conexão é iniciada. Por exemplo, no caso de TCP/IP, a pena de inicialização de ligação ocorre devido tanto ao tempo tomado para o “aperto de mão”/“handshake” TCP inicial para estabelecer a ligação e o tempo tomado para o protocolo de controle de congestão para atingir a utilização total da largura de banda disponível.

[000352]Neste caso, pode ser desejável emitir pedidos múltiplos, utilizando uma única ligação, a fim de reduzir a freqüência com que a pena de conexão de inicialização é constituída. No entanto, alguns protocolos de transporte de arquivos, por exemplo, HTTP, não fornecem um mecanismo para cancelar um pedido, além de fechar a conexão da camada de transporte de todo e, assim, incorrer numa pena de conexão de inicialização quando uma nova conexão é estabelecida no lugar do antigo. Uma solicitação emitida pode precisar ser cancelada, se for determinado que a largura de banda disponível mudou e uma diferente meios taxa de dados é necessária em vez disso, ou seja, há uma decisão para mudar para uma representação diferente. Outra razão para o cancelamento de um pedido pode ser emitido se o usuário solicitou que a apresentação de mídia ser encerrada e uma nova apresentação começou (talvez do mesmo item de conteúdo em um ponto diferente na apresentação, ou talvez de um novo item de conteúdo).

[000353]Como é sabido, a pena de inicialização de ligação pode ser evitada, mantendo-se a ligação/conexão aberta e voltar a usar a mesma conexão para pedidos subseqüentes e, como também é conhecido, a ligação pode ser mantida totalmente utilizada se vários pedidos são emitidos ao mesmo tempo sobre a mesma conexão/ligação (uma técnica conhecida como “pipelining”, no contexto de HTTP). No entanto, uma desvantagem de emissão de pedidos múltiplos, ao mesmo tempo, ou, mais geralmente, de tal maneira que vários pedidos são emitidos antes que pedidos anteriores terem se completado através de uma ligação, pode ser que a ligação é então comprometida com a execução da resposta a estes pedidos e então, se mudanças a que os pedidos devem ser emitidos tornam-se desejáveis, a conexão pode ser fechada se torna-se necessário cancelar pedidos já emitidos que não são mais desejados.

[000354]A probabilidade de que um pedido emitido precisa ser cancelado pode ser, em parte, dependente da duração do intervalo de tempo entre a emissão do pedido e do tempo de reprodução do bloco solicitado no sentido de que, quando este intervalo de tempo é elevado a probabilidade de que um pedido emitido precisa ser cancelado é também elevada (porque é provável que a largura de banda disponível mude durante o intervalo).

[000355]Como é sabido, alguns protocolos de download de arquivo têm a propriedade de que uma conexão com uma única camada subjacente de transporte pode ser vantajosamente utilizada para vários pedidos de transferência. Por exemplo, o HTTP tem esta propriedade, uma vez que a reutilização de uma única conexão para múltiplas solicitações evita a pena de conexão de inicialização descrita acima para outras solicitações que não a primeira. No entanto, uma desvantagem dessa abordagem é que a conexão está empenhada em transportar os dados solicitados em cada pedido emitido e, portanto, se um pedido ou pedidos têm de ser cancelados em seguida, a conexão pode ser fechada, incorrendo na pena de conexão de inicializaçã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 atraso na recepção de dados subseqüentes.

[000356] Será agora descrita uma modalidade que retém as vantagens da reutilização da conexão sem incorrer nesta desvantagem e que também aumenta a freqüência com que as conexões podem ser reutilizadas.

[000357]As modalidades dos sistemas de streaming por solicitação de blocos aqui descritos são configuradas para reutilizar uma conexão para vários pedidos sem ter que comprometer a conexão no início de um determinado conjunto de solicitações. Essencialmente, um novo pedido é emitido em uma conexão existente quando os pedidos já emitidos sobre a ligação ainda não tenham se completado, mas estão em fase de conclusão. Uma razão para não esperar até que os pedidos existentes se completem é que se os pedidos anteriores se completam, então a velocidade de conexão pode se degradar, ou seja, a sessão TCP subjacente, poderia entrar em um estado inativo, ou a variável de TCP cwnd poderia ser substancialmente reduzida, reduzindo assim substancialmente a velocidade de download inicial do novo pedido emitido nessa conexão. Uma razão para esperar até próximo da conclusão antes de emitir um pedido adicional é porque se um novo pedido for emitido muito antes de os anteriores pedidos completos, então o novo pedido emitido não pode mesmo começar por algum período de tempo substancial, e que poderia ser o caso que durante este período de tempo antes que o novo pedido emitido começa a decisão de fazer o novo pedido não é mais válido, por exemplo, devido a uma decisão de mudar representações. Assim, incorporação de clientes que implementam esta técnica irá emitir um novo pedido em uma conexão o mais tarde possível sem abrandar as capacidades de transferência da conexão.

[000358]O método compreende o controle do número de bytes recebidos de uma ligação, em resposta ao último pedido emitido nesta conexão e aplicando um teste para esse número. Isto pode ser feito fazendo com que o receptor (ou do transmissor, se aplicável) configurado para monitorar e testar.

[000359] Se o teste “passar” isto é, for aprovado, em seguida, um novo pedido pode ser emitido na conexão. Um exemplo de um ensaio adequado é se o número de bytes recebidos é maior do que uma fração fixa do tamanho dos dados pedidos. Por exemplo, esta fração pode ser de 80%. Outro exemplo de um ensaio adequado baseia-se o seguinte cálculo, tal como ilustrado na Figura 17. No cálculo, seja R uma estimativa da taxa de dados da ligação, T uma estimativa do tempo de ida e volta ("RTT") e X o fator numérico que, por exemplo, poderia ser um conjunto de constantes para um valor entre 0,5 e 2, onde as estimativas de R e T são atualizados em uma base regular (atualizado na etapa 1410). Seja S o tamanho dos dados requeridos no último pedido, B é o número de bytes dos dados requeridos recebidos (calculado na etapa 1420).

[000360]Um teste adequado seria fazer o receptor (ou o transmissor, se aplicável) executar uma rotina para avaliar a desigualdade (SB) <X • R • T (tstate na etapa 1430), e se a resposta for "Sim", encetar uma ação. Por exemplo, um teste poderia ser feito para ver se há outro pedido pronto para ser emitido na conexão (tstate na etapa 1440), e se for "Sim", em seguida, emitir o pedido 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 testando. Se o resultado do teste na etapa 1430 for “não” em seguida o processo retorna para a etapa 1410 para continuar a atualização e testando.

[000361]O teste da desigualdade na etapa 1430 (realizada por elementos adequadamente programados, por exemplo) faz com que cada pedido subseqüente seja emitido quando a quantidade de dados a serem recebidos restantes é igual a X vezes a quantidade de dados que pode ser recebido na taxa de recepção atual estimada em um RTT (tempo de ida e volta). Um certo número de métodos para estimar a taxa de dados, R, na etapa 1410 são conhecidos pelos técnicos na área. Como exemplo, a taxa de dados pode ser estimada como DT/t, em que Dt é o número de bits recebidos nos segundos t precedentes 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 de filtro de primeira ordem de resposta de impulso infinito (IIR) da taxa de dados de entrada. Um certo número de métodos para estimar a RTT, T, na etapa 1410 são conhecidos pelos técnicos na área.

[000362]O teste na etapa 1430 pode ser aplicado para o total de todas as ligações ativas sobre uma interface, como explicado em maiores detalhes mais adiante.

[000363]O método inclui ainda a construção de uma lista de requisições/pedidos candidatos, associando cada pedido candidato com um conjunto de servidores adequados para que o pedido possa ser feito e ordenando a lista de pedidos de candidatos em ordem de prioridade. Algumas entradas na lista de pedidos de candidatos podem ter a mesma prioridade. Servidores na lista de servidores adequados associados a cada pedido candidatos são identificados por nomes de “hosts”. Cada hostname corresponde a um conjunto de endereços de Protocolo de Internet que podem ser obtidos a partir do DNS - Domain Name System (sistema de nomes de domínios) como é bem conhecido. Por conseguinte, cada possível pedido na lista de pedidos candidatos está associado com um conjunto de endereços de Protocolo de Internet, especificamente a união dos conjuntos de endereços de IP (Protocolo de Internet) associados aos nomes das máquinas associados com os servidores associados com o pedido candidato. Sempre que o teste descrito na etapa 1430 é atendido para uma conexão, e nenhum novo pedido ainda foi emitido nessa conexão, o pedido de prioridade nas listas de pedidos de candidatos com os quais o endereço do Protocolo Internet do destino da ligação está associada é escolhido, e este pedido é emitido na conexão. O pedido também é removido da lista de pedidos candidatos.

[000364]Os pedidos candidatos podem ser removidos (cancelados) da lista de solicitações candidatas, novos pedidos podem ser adicionados à lista de candidatas com uma prioridade maior do que pedidos já existentes sobre a lista de candidatas, e os pedidos existentes na lista de candidatas podem ter a sua prioridade alterada. A natureza dinâmica de quais pedidos estão na lista de pedidos candidatos, e a natureza dinâmica da sua prioridade na lista de candidatos, que podem alterar os pedidos pode ser emitido próxima dependem de quando um teste do tipo descrito na etapa 1430 é atendido.

[000365]Como exemplo, poderia ser possível que, se a resposta ao teste descrito na etapa 1430 for "Sim" em algum tempo t, em seguida, o próximo pedido seria emitido um pedido A, enquanto que se a resposta ao teste descrito na etapa 1430 não é "Sim"até algum tempo t'> t, então a próxima solicitação emitida passaria a ser um pedido B, porque ou um pedido foi retirado da lista de pedidos candidatos entre os tempos t e t', ou porque um pedido B foi adicionado à lista de pedidos candidatos com maior prioridade do que um pedido de tempo entre t e t', ou porque foi inserido um pedido B na lista de candidatos no tempo t, mas com menor prioridade do que um pedido A, e entre o tempo t e t' a prioridade de pedido B foi tornada maior do que a solicitação de A.

[000366]A Figura 18 ilustra um exemplo de uma lista de pedidos na lista de candidatos de pedidos. Neste exemplo, existem três ligações, e há seis pedidos na lista de candidatos, identificado como A, B, C, D, E e F. Cada uma das solicitações na lista de candidatos podem ser emitidos com um subconjunto das ligações como indicado, o pedido, por exemplo, A pode ser emitido em conexão 1, enquanto F pedido pode ser emitido em conexão 2 ou uma conexão 3. A prioridade de cada pedido está também marcada na fig. 18, e um valor de prioridade mais baixa indica que uma solicitação é maior prioridade. Assim, os pedidos A e B com 0 prioritárias são as solicitações de maior prioridade, enquanto F pedido com um valor de prioridade 3 é a prioridade mais baixa entre os pedidos na lista de candidatos.

[000367]Caso, neste momento, no tempo t, a ligação 1 passa no teste descrito na etapa de 1430, a requisição A ou B é emitido na conexão 1. Se em lugar disto a conexão 3 passa no teste descrito na etapa 1430 neste tempo t, então D é emitida na conexão 3, uma vez que D é o pedido com a maior prioridade que pode ser emitido na conexão 3.

[000368]Vamos supor que, para todas as conexões a resposta ao teste descrito na etapa 1430 do tempo t para algum tempo depois t' for "Não", e entre o tempo t e t' a solicitação muda sua prioridade de 0 para 5, o pedido B é removido da lista do candidato, e um novo pedido G com prioridade 0 é adicionado à lista de candidatos. Em seguida, no tempo t', a lista de novos candidatos pode estar como mostrado na Figura 19.

[000369]Caso no momento t’ a conexão 1 passa no teste descrito na etapa 1430, então a requisição C com prioridade 4 é emitida na conexão 1, pois ela é o pedido de maior prioridade na lista de candidatos que podem ser emitidos na conexão 1 neste ponto no tempo.

[000370]Vamos supor na mesma situação que, em lugar disto a requisição A teria sido emitida na conexão 1 no tempo t (que era uma das duas escolhas de mais alta prioridade para a conexão 1 no tempo t, como mostrado na Figura 18). Como a resposta ao teste descrito na etapa 1430 do tempo t para algum tempo depois t'é “Não” para todas as conexões, a conexão 1 ainda está fornecendo dados até, pelo menos, o tempo t’ para as solicitações emitidas antes do tempo t e, portanto, a requisição A não teria começado pelo menos até o tempo t'. A emissão da requisição C no tempo t'é uma decisão melhor do que a emissão da requisição A no tempo t, dado que a requisição C começa ao mesmo tempo após t' que a requisição A teria iniciado, e dado que neste momento a requisição C é de maior prioridade que o pedido A.

[000371]Como outra alternativa, se o teste do tipo descrito na etapa 1430 é aplicado ao agregado das ligações ativas uma ligação podem ser escolhida possuindo um destino cujo endereço IP está associado com o primeiro pedido na lista de pedidos candidatos ou outro pedido com a mesma prioridade que o primeiro pedido.

[000372]Vários métodos são possíveis para a construção da lista de pedidos candidatos. Por exemplo, a lista de candidatos pode conter n pedidos representando pedidos para n próximas porções dados da representação atual da apresentação em ordem de seqüência de tempo, em que o pedido para a primeira parte dos dados tem maior prioridade e o pedido para a última parte de dados que tem menor prioridade. Em alguns casos n pode ser um. O valor de n pode depender do tamanho do buffer, Bcurrent, ou a variável de state ou outra medida do estado de ocupação do buffer de cliente. Por exemplo, um número de valores limite pode ser definido para Bcurrent e um valor associado a cada limite e, em seguida, o valor de n é considerado como sendo o valor associado com a maior limite que é menor do que Bcurrent.

[000373]A modalidade acima descrita garante alocação flexível dos pedidos de conexões, garantindo que a preferência é dada para a reutilização de uma conexão existente, mesmo se o pedido de prioridade não é adequado para essa conexão (porque o endereço IP de destino da ligação não é aquele que é atribuído a qualquer um dos hostnames associados com o pedido). A dependência de n de Bcurrent ou State ou de outra medida da ocupação do buffer cliente garante que tais pedidos/requisições “fora da ordem de prioridades”, tais pedidos não são emitidos quando o cliente tem necessidade urgente de emissão e conclusão do pedido associado a próxima porção de dados para ser reproduzido na seqüência do tempo.

[000374]Estes métodos podem ser vantajosamente combinados com HTTP e FEC cooperativos.

Seleção de Servidor Consistente

[000375]Como é bem conhecido, os arquivos a serem baixados usando um protocolo de download de arquivos são normalmente identificadas por um identificador que compreende um host e um nome de arquivo. Por exemplo, este é o caso para o protocolo HTTP, caso em que o identificador é um identificador de recursos uniforme (URI). Um hostname pode corresponder a vários hosts identificados por endereços Internet Protocol. Por exemplo, este é um método comum de espalhar a carga de pedidos de vários clientes em várias máquinas físicas. Em particular, esta abordagem é normalmente tomada por redes “Content Delivery” (CDN). Neste caso, um pedido emitido em conexão com qualquer um dos hospedeiros/hosts físicos deverá ter sucesso. Um certo número de métodos são conhecidos através da qual um cliente pode selecionar de entre o Protocolo de Internet endereços associados com um host. Por exemplo, esses endereços são normalmente fornecidos para o cliente através do Sistema de Nomes de Domínio e são fornecidos em ordem de prioridade. Um cliente pode então escolher a mais alta prioridade (primeiro) de endereços do protocolo Internet. No entanto, geralmente não há coordenação entre os clientes sobre a forma como esta escolha é feita, com o resultado de diferentes clientes podem solicitar o mesmo arquivo de diferentes servidores. Isso pode resultar no mesmo arquivo que ser armazenado no cache de vários servidores próximos, o que reduz a eficiência da infra-estrutura de cache.

[000376] Isto pode ser gerenciado por um sistema que vantajosamente aumenta a probabilidade de que dois clientes que requerem o mesmo bloco irão solicitar este bloco a partir do mesmo servidor. O novo método aqui descrito compreende a seleção dentre os endereços de Protocolo de Internet disponíveis de uma forma determinada pelo identificador do arquivo a ser solicitado e de tal forma que os clientes diferentes apresentados com as mesmas escolhas ou similares de endereços Internet Protocol e identificadores de arquivo irá fazer a mesma escolha.

[000377]Uma primeira modalidade do método é descrita com referência à Figura 20. O cliente primeiro obtém um conjunto de Protocolo de Internet IP1, IP2, ..., IPn, tal como mostrado na etapa 1710. Se houver um arquivo para o qual pedidos devem ser emitidos, tal como decidido na etapa 1720, o cliente determina qual endereço de Protocolo Internet para emitir solicitações para o arquivo, como determinado nas etapas 1730 a 1770. Dado um conjunto de endereços de protocolo de Internet e um identificador para um arquivo a ser solicitado o método compreende ordenar o Protocolo de Internet de uma forma determinada pelo identificador de arquivo. Por exemplo, para cada endereço de Protocolo Internet uma seqüência de bytes é construída compreendendo a concatenação do endereço de Protocolo Internet e o identificador de arquivo, como mostrado na etapa 1730. Uma função hash é aplicada a esta cadeia de bytes, como mostrado na etapa 1740, e os valores resultantes hash são dispostos de acordo com uma ordenação fixa, como mostrado na etapa 1750, por exemplo aumentando o número de ordem, induzindo uma ordenação sobre os endereços de Protocolo de Internet. A mesma função hash pode ser utilizada por todos os clientes, garantindo assim que o mesmo resultado é produzido pela função hash sobre uma dada entrada por todos os clientes. A função de hash pode ser configurado estaticamente para todos os clientes em um conjunto de clientes, ou todos os clientes em um conjunto de cliente pode obter uma descrição parcial ou total da função hash quando os clientes obter a lista de endereços de Internet Protocol, ou todos os clientes em um conjunto de cliente pode obter uma descrição parcial ou total da função hash quando os clientes obter o identificador de arquivo, ou a função hash pode ser determinada por outros meios. O endereço de Protocolo de Internet que é o primeiro nesta ordem é escolhido e este endereço é então usado para estabelecer uma conexão pedidos e emissão para todo ou partes do arquivo, como mostrado nos passos 1760 e 1770.

[000378]O método acima pode ser aplicado quando uma nova conexão é estabelecida para solicitar um arquivo. Também pode ser aplicado quando um número de conexões estabelecidas estão disponíveis e um deles pode ser escolhido para emitir um novo pedido.

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

[000380]Este método apresenta vantagens pela seguinte razão: uma abordagem típica tomada por uma infra-estrutura servidora de blocos como aquela mostrada na Figura 1 (BSI 101) ou Figura 2 (BSIs 101), e em particular uma abordagem comumente tomada por CDNs, é a de fornecer vários servidores proxy cache que recebem solicitações de clientes. Um servidor proxy cache não pode ser provido com o arquivo solicitado em uma determinada solicitação e, neste caso, tais servidores tipicamente encaminham a solicitação para outro servidor, recebem a resposta de tal servidor, tipicamente incluindo o arquivo solicitado, e repassa a resposta ao cliente. O servidor proxy de cache pode também armazenar (cache) do arquivo solicitado para que ele possa responder imediatamente às solicitações subseqüentes para o arquivo. A abordagem comum descrita acima tem a propriedade de que o conjunto de arquivos armazenados em um determinado servidor proxy cache é largamente determinado pelo conjunto de solicitações que o servidor proxy cache recebeu.

[000381]O método descrito acima tem a seguinte vantagem. Caso todos os clientes em um conjunto de clientes recebem a mesma lista de endereços de Internet Protocol, em seguida, estes clientes irão utilizar o mesmo endereço do Protocolo Internet para todos os pedidos emitidos para o mesmo arquivo. Se há duas listas diferentes de endereços de protocolo de Internet e cada cliente recebe uma dessas duas listas, os clientes irão utilizar no máximo dois endereços de protocolo de Internet diferentes para todos os pedidos emitidos para o mesmo arquivo. Em geral, se as listas de endereços Internet Protocol providas aos clientes são semelhantes, os clientes usarão um pequeno conjunto de endereços de protocolo de Internet fornecidos para todos os pedidos emitidos para o mesmo arquivo. Como os clientes próximos tendem a receber listas similares de endereços de protocolo de Internet, é provável que próximas solicitações de clientes que visem um arquivo de apenas uma pequena parcela dos servidores proxy cache disponíveis para esses clientes. Assim, haverá apenas uma pequena fração de cache de servidores proxy que a cache de arquivos, que vantajosamente minimiza a quantidade de recursos de cache usadas para armazenar o arquivo.

[000382]De preferência, a função hash tem a propriedade de que uma fração muito pequena de diferentes entradas são mapeados para a mesma saída, e que diferentes entradas são mapeados para saídas essencialmente aleatórias, para assegurar que, para um dado conjunto de endereços de Protocolo de Internet, a proporção de arquivos para o qual um dado um dos endereços de Protocolo de Internet é em primeiro lugar na lista classificada produzido pela etapa 1750 é aproximadamente a mesma para todos os endereços de Protocolo de Internet na lista. Por outro lado, é importante que a função hash é determinística, no sentido de que para uma dada entrada a saída da função hash é a mesma para todos os clientes.

[000383]Outra vantagem do método descrito acima é o seguinte. Vamos supor que todos os clientes em um conjunto de clientes são fornecidos com a mesma lista de endereços de Internet Protocol. Por causa das propriedades da função hash que acabamos de descrever, é provável que os pedidos de arquivos diferentes desses clientes será uniformemente distribuído em todo o conjunto de endereços de Protocolo de Internet, o que por sua vez significa que os pedidos serão distribuídos uniformemente pelos cache dos servidores proxy. Dessa forma, os recursos de cache usados para armazenar esses arquivos são distribuídos uniformemente entre os servidores de proxy cache, e os pedidos de arquivos é distribuído uniformemente entre os servidores de proxy cache. Assim, o método proporciona tanto o balanceamento de armazenamento e equilíbrio de carga em toda a infra-estrutura cache.

[000384]Diversas variações para a abordagem descrita acima são conhecidos pelos técnicos na área e, em muitos casos, essas variações retêm a propriedade de que o conjunto de arquivos armazenados em um proxy é determinado pelo menos em parte pelo conjunto de solicita ao servidor proxy cache recebeu. No caso comum em que um dado hostname resolve para múltiplos servidores proxy cache físicos, será comum que todos esses servidores, eventualmente, vão armazenar uma cópia de qualquer arquivo, dado que é freqüentemente solicitado. Esta duplicação pode ser indesejável, uma vez que os recursos de armazenamento nos servidores de proxy cache são limitados e, como arquivos de resultado pode ser, na ocasião, removido (expurgados) do cache. O novo método aqui descrito assegura que os pedidos de um arquivo de dados são dirigidos para o cache de servidores proxy de tal maneira que este duplicação é reduzido, reduzindo assim a necessidade de remover os arquivos do cache e aumentando assim a probabilidade de que qualquer dado arquivo está presente (isto é, não foi purgado da) na memória do cache proxy.

[000385]Quando um arquivo está presente no cache proxy, a resposta enviada para o cliente é mais rápida, o que tem a vantagem em reduzir a probabilidade de que o arquivo pedido chegue tarde, o que pode resultar em uma pausa nos meios de reprodução e, portanto, uma má experiência para o usuário. Além disso, quando um arquivo não estiver presente no cache do proxy o pedido pode ser enviado para outro servidor, causando carga adicional tanto sobre a infraestrutura servidora como sobre as conexões de rede entre os servidores. Em muitos casos, o servidor ao qual o pedido é enviado pode estar em um local distante e a transmissão do arquivo a partir deste servidor para o servidor proxy cache pode incorrer em custos de transmissão. Por conseguinte, o novo método aqui descrito resulta numa redução de tais custos de transporte.

Requisições Probabilísticas de Arquivos Completos

[000386]Uma preocupação em particular no caso em que o protocolo HTTP é usado com solicitações de intervalo é o comportamento de servidores de cache que são comumente utilizados para fornecer escalonamento da infra-estrutura servidora. Embora possa ser comum para os servidores de cache HTTP dar suporte ao cabeçalho de faixa HTTP, o comportamento exato de servidores de cache HTTP diferentes varia de acordo com a implementação. A maioria das implementações de servidor de cache atende às solicitações de faixa do cache no caso em que o arquivo está disponível no cache. Uma implementação comum de servidores HTTP Cache sempre encaminha solicitações HTTP a jusante contendo cabeçalho de intervalo para um nodo a montante, a menos que o servidor de cache tenha uma cópia do arquivo (servidor de cache ou servidor de origem). Em algumas implementações a resposta a montante da Faixa de pedido é o arquivo inteiro, e esse arquivo é armazenado em cache e a resposta ao pedido de Faixa é extraído deste arquivo e enviado. No entanto, em pelo menos uma implementação a resposta a montante para o pedido Faixa é apenas os bytes de dados no próprio pedido de faixa, e estes bytes de dados não são armazenados mas em vez disso simplesmente enviados como a resposta ao pedido de faixa a jusante. Como resultado, o uso de cabeçalhos de Faixa por clientes pode ter como conseqüência que o arquivo em si nunca é levado a caches e as propriedades desejáveis de escalonamento da rede serão perdidas.

[000387]No que precede, foi descrita a operação de servidores proxy cache e também o método de solicitação de Blocos de um arquivo que é uma agregação de vários blocos. Como exemplo, isto pode ser conseguido através da utilização do cabeçalho da solicitação de faixa HTTP. Tais solicitações são chamados de “pedidos parciais” no que se segue. Uma outra modalidade será agora descrita, que tem vantagem no caso em que a infraestrutura de blocos 101 não fornece suporte completo para o cabeçalho de intervalo/faixa HTTP. Comumente, os servidores dentro de uma infraestrutura servidora de blocos, por exemplo, uma Content Delivery Network, suportam os pedidos parciais, mas não podem armazenar a resposta aos pedidos parciais de armazenamento local (cache). Esse servidor pode atender a um pedido parcial, por encaminhar o pedido para outro servidor, a menos que todo o arquivo esteja armazenado na memória local, caso em que a resposta pode ser enviada sem encaminhar o pedido para outro servidor.

[000388]Um sistema de streaming por solicitação de blocos que faz uso do aperfeiçoamento de agregação de blocos descrito acima pode ser executar de forma deficiente caso a infraestrutura servidora de blocos apresenta esse comportamento, porque todas as solicitações, sendo pedidos parciais, será encaminhado para outro servidor e nenhuma solicitação será servida por servidores proxy cache, impossibilitando o objeto de prover os servidores proxy cache em primeiro lugar. Durante o processo do sistema de streaming por solicitação de blocos como descrito acima, um cliente pode, em algum ponto requisitar um bloco que esteja no início de um arquivo.

[000389]De acordo com o novo método aqui descrito, sempre que uma determinada condição seja atendida, tais pedidos podem ser convertidos a partir de solicitações para o primeiro bloco em um arquivo de pedidos de todo o arquivo. Quando um pedido de todo o arquivo é recebido por um servidor proxy cache do servidor proxy normalmente armazena a resposta. Portanto, o uso desses pedidos faz com que o arquivo a ser trazido para o cache dos servidores de cache local procuração que as solicitações subseqüentes, seja para o arquivo completo ou pedidos parciais podem ser servidos diretamente pelo servidor proxy cache. A condição pode ser tal que, entre um conjunto de solicitações associados com um dado arquivo, por exemplo o conjunto de solicitações geradas por um conjunto de clientes visualizaram o item de conteúdo em questão, a condição será satisfeita por pelo menos uma fração desde destes pedidos.

[000390]Um exemplo de uma condição adequada é a de que um número escolhido aleatoriamente está acima de um limiar fornecido. Este limiar pode ser definido de tal forma que a conversão de um pedido de único bloco em um pedido de arquivo completo ocorre, em média, para uma fração provida dos pedidos, por exemplo um vez de cada dez (caso em que o número aleatório pode ser escolhido a partir do intervalo [0, 1] e o limite pode ser 0,9). Outro exemplo de uma condição adequada é a de que uma função hash calculada ao longo de algumas informações associadas com o bloco e alguma informação associada com o cliente tem uma de um conjunto de valores fornecido. Este método tem a vantagem de que para um arquivo que é freqüentemente requerido, o processo será levado para o cache de um servidor proxy local, todavia o funcionamento do sistema de transmissão de pedido de bloco não é alterada significativamente a partir da operação padrão em que cada solicitação é para um único bloco. Em muitos casos, onde a conversão do pedido a partir de um pedido único bloco a uma solicitação de arquivo inteiro ocorre, os procedimentos de cliente, de outro modo ir para solicitar os outros blocos dentro do arquivo. Se este for o caso, então esses pedidos podem ser suprimida porque os blocos em questão vai ser recebido em qualquer caso, como um resultado do pedido arquivo completo.

Construção URL e Geração e Pesquisa de Lista de segmentos

[000391]A geração da lista de segmentos lida com a questão de como um cliente pode gerar uma lista de segmentos a partir do MPD em um momento NOW de tempo local de cliente para uma representação específica que se inicia em algum starttime/hora de início, quer em relação ao início da apresentação dos meios para casos on demand ou expressada em tempo de relógio. Uma lista de segmentos pode compreender um localizador por exemplo de um URL para uma representação de metadados opcional inicial, bem como uma lista de segmentos de meios de comunicação. A cada segmento de meios de comunicação pode ter sido atribuído um starttime, uma duração e um localizador. O starttime tipicamente expressa uma aproximação do tempo de mídia da mídia contida em um segmento, mas não necessariamente um tempo de amostra exata. O starttime é usado pelo cliente de fluxo contínuo de HTTP para emitir o pedido de download no momento apropriado. A geração da lista de segmento, incluindo o tempo de início de cada um, pode ser feita de formas diferentes. O URLs podem ser fornecidos como uma lista de leitura ou uma regra de construção URL pode ser vantajosamente utilizado para uma representação compacta da lista de segmentos.

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

Construção URL - Visão Geral

[000393]Como foi acima descrito, em uma modalidade da presente invenção pode ser proporcionado um arquivo de metadados contendo regras de URL de construção que permitem dispositivos de cliente construir os identificadores de arquivo para blocos de apresentação. Será descrito agora um acessório novo para o sistema de streaming por solicitação de blocos que prevê alterações no arquivo de metadados, incluindo as alterações às regras de construção de URL, alterações no número de codificações disponíveis, mudanças de metadados associados com as codificações disponíveis, tais como o bitrate, relação de aspecto, resolução de áudio, vídeo ou parâmetros de codec ou codec e outros parâmetros.

[000394]Neste novo aperfeiçoamento podem ser fornecidos dados adicionais associados com cada elemento do arquivo de metadados indicando um intervalo de tempo dentro da apresentação global. Dentro deste intervalo de tempo o elemento pode ser considerado válido e de outra forma o intervalo de tempo o elemento pode ser ignorada. Além disso, a sintaxe dos metadados pode ser aumentada de forma que os elementos previamente autorizados a aparecer apenas uma vez ou no máximo uma vez pode aparecer várias vezes. Uma restrição adicional pode ser aplicado no presente caso, que prevê que, para tais elementos os intervalos de tempo especificados deve ser separado. Em qualquer instante de tempo determinado, considerando somente os elementos cujo tempo de intervalo contém os resultados de tempo dadas instantâneas em um arquivo de metadados que é consistente com a sintaxe de metadados original. Chamamos a intervalos de tempo tais intervalos de validade. Este método fornece, portanto, para a sinalização dentro de algumas alterações de metadados de arquivo único do tipo descrito acima. Vantajosamente, tal método pode ser usado para fornecer uma apresentação dos meios que suporta mudanças do tipo descrito em pontos específicos no interior da apresentação.

Construtor de URL

[000395]Tal como aqui descrito, uma característica comum dos sistemas de streaming por solicitação de blocos é a necessidade de fornecer ao cliente “metadados” que identificam as codificações de mídia disponíveis e fornecem as informações necessárias para cliente para solicitar os blocos dessas codificações. Por exemplo, no caso de HTTP, esta informação pode incluir URLs para os arquivos contendo os blocos de meios de comunicação. Um arquivo de lista de reprodução pode ser fornecido que lista as URLs para os blocos de uma determinada codificação. Vários arquivos de lista de reprodução são fornecidos, um para cada codificação, juntamente com uma lista mestre de playlists que lista as listas correspondentes aos diferentes codificações. Uma desvantagem deste sistema é que o metadados pode tornar-se muito grande e, por conseguinte, leva algum tempo para ser requerida quando o cliente começa a transmitir. Uma outra desvantagem deste sistema é evidente, no caso do conteúdo ao vivo, quando os arquivos correspondentes aos blocos de suportes de dados são gerados “on the fly”/“em percurso” a partir de um fluxo de meios de comunicação que está a ser capturado em tempo real (viva), por exemplo um vivo eventos desportivos ou programa de notícias. Neste caso, os arquivos da lista pode ser atualizada cada vez que um novo bloco está disponível (por exemplo a cada poucos segundos). Dispositivos clientes podem repetidamente buscar o arquivo de playlist para determinar se novos blocos estão disponíveis e obter a sua URL. Isto pode colocar uma carga significativa na infra- estrutura que serve e em meios particulares que arquivos de metadados não podem ser armazenadas durante mais tempo do que o intervalo de atualização, que é igual ao tamanho do bloco que é comumente da ordem de alguns segundos.

[000396]Um aspecto importante de um sistema de solicitação de bloco de transmissão é o método utilizado para informar os clientes dos identificadores de arquivo, por exemplo, URLs, que deve ser usado, juntamente com o protocolo de download de arquivo, para solicitar blocos. Por exemplo, um método em que para cada representação de uma apresentação é proporcionado um arquivo de lista que lista os URLs dos arquivos contendo os blocos de dados multimídia. Uma desvantagem deste método é que, pelo menos, algum do arquivo de lista si precisa ser descarregado antes de reprodução pode começar, aumentando o canal zapping tempo e, por conseguinte, causando uma experiência de utilizador pobre. Para uma apresentação de mídia longa com várias representações ou muitos, a lista de URLs arquivo pode ser grande e, portanto, o arquivo de lista pode ser grande aumentando ainda mais o tempo de zapping de canais.

[000397]Outra desvantagem deste método ocorre no caso de o conteúdo ao vivo. Neste caso, a lista completa de URLs não é disponibilizado com antecedência e o arquivo lista é atualizada periodicamente como novos blocos se tornam disponíveis e os clientes exigem, periodicamente, o arquivo de lista de reprodução, a fim de receber a versão atualizada. Porque este arquivo é atualizado com freqüência, não pode ser armazenado por muito tempo dentro dos servidores proxy cache. Isto significa que muitos dos pedidos para este arquivo será enviado para outros servidores e, eventualmente, para o servidor que gera o arquivo. No caso de uma apresentação dos meios populares este pode resultar em uma carga elevada no servidor e da rede, que pode por sua vez, resultam em um tempo de resposta lento e, portanto, um elevado tempo de zapping de canais e uma pobre experiência para o utilizador. No pior caso, o servidor fica sobrecarregado e isso resulta em alguns usuários que são incapazes de ver a apresentação.

[000398]É desejável na concepção de um sistema de streaming por solicitação de blocos evitar restrições colocadas sobre a forma dos identificadores de arquivo que podem ser utilizados. Isto porque uma série de considerações pode motivar a utilização de identificadores de uma forma particular. Por exemplo, no caso em que a infraestrutura servidora de blocos é uma rede de distribuição de conteúdo pode haver de convenções de nomenclatura de arquivos ou de armazenamento relacionadas com o desejo de distribuir o armazenamento ou servir a carga através da rede ou outros requisitos que levam a determinadas formas de identificador de arquivo que não podem ser previsto no momento da concepção do sistema.

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

[000400]Em uma modalidade, a regra de construção do identificador de arquivo pode compreender uma cadeia ou string de texto que pode conter certos identificadores especiais correspondentes aos parâmetros de entrada. O método de avaliação da regra de construção de identificador de arquivo compreende determinar as posições dos identificadores especiais dentro da cadeia de texto e substituindo cada um de tais identificadores especiais com uma representação string do valor do parâmetro de entrada correspondente.

[000401]Em outra modalidade, a regra de construção de identificador de arquivo pode compreender uma seqüência de texto em conformidade com uma linguagem de expressão. Uma linguagem de expressão compreende a definição de uma sintaxe para que expressões na linguagem possam se conformar e um conjunto de regras para avaliar um string em conformidade com a sintaxe.

[000402] Será agora descrito um exemplo específico, com referência à Figura 21 e seguintes. Um exemplo de uma definição de sintaxe para uma linguagem de expressão adequada, definida em Forma Backus-Naur Aampliada, é como mostrado na Figura 21. Um exemplo de regras para avaliar uma cadeia em conformidade com a produção <expression> na Figura 21 compreende transformar recursivamente o string conformant para a produção <expression> (um <expression>) em um string conformant para a produção <literal> como se segue: Um conformant <expression> para a produção <literal> permanece inalterado. Um conformant <expression> para a produção <variable>é substituído com o valor da variável identificado pela cadeia <token> da produção <variable>. Um conformant <expression> para a produção <function>é avaliado por avaliação de cada dos seus argumentos de acordo com estas regras e aplicando uma transformação para estes argumentos dependentes do elemento <token> da produção <function> como descrito abaixo. Um conformant <expression> para a última alternativa da produção <expression>é avaliada por meio da avaliação dos dois elementos <Expression> e aplicando uma operação para estes argumentos dependentes do elemento <operator> da última alternativa da <expression>produção como descrito abaixo.

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

[000404]Um exemplo de uma função é a função "printf". Esta função aceita um ou mais argumentos. O primeiro argumento pode ser conformant à produção <string> (doravante um "string"). A função printf é avaliada como uma versão transformada de seu primeiro argumento. A transformação utilizada é a mesma como a função "printf" da biblioteca padrão C, com os argumentos adicionais incluídos na produção <function> fornecendo os argumentos adicionais até a função de biblioteca C padrão printf.

[000405]Outro exemplo de uma função é a função "hash". Esta função aceita dois argumentos, o primeiro dos quais pode ser uma string e a segunda de que pode ser conformant à produção <número>(a seguir um “número”). A função "hash" aplica um algoritmo de hash para o primeiro argumento e retorna um resultado que é um número inteiro não negativo menor do que o segundo argumento. Um exemplo de uma função hash é adequado dada na função C mostrado na fig. 22, cujos argumentos são a cadeia de entrada (excluindo as aspas encerram) e o valor de entrada numérico. Outros exemplos de funções hash são bem conhecidos dos peritos na arte.

[000406]Outro exemplo de uma função é o "subst"função que tem argumentos de cadeia de um, dois ou três. No caso em que um argumento é fornecido o resultado da função "Subst"é o primeiro argumento. No caso em que dois argumentos forem fornecidos, o resultado da função "Subst"é calculado pela eliminação de todas as ocorrências do segundo argumento (excluindo as aspas encerram), no primeiro argumento e retorna o primeiro argumento tão modificado. No caso em que três argumentos forem fornecidos, o resultado da função "Subst"é calculado através da substituição de todas as ocorrências do segundo argumento (excluindo as aspas encerram) dentro do primeiro argumento com o terceiro argumento (excluindo as aspas encerram) e retornando o primeiro argumento tão modificado.

[000407]Alguns exemplos de operadores são a adição, subtração, divisão, multiplicação e operadores módulo, identificado pelo produções <operador>'+', '', '/', '*', '%', respectivamente. Essas operadoras exigem que as produções <Expression> cada um dos lados da produção <operador> avaliar em números. A avaliação do operador compreende a aplicação a operação aritmética apropriado (adição, subtração, divisão de multiplicação, e módulo, respectivamente) para estes dois números da maneira usual e retornando o resultado de uma forma compatível com a produção <número>.

[000408]Outro exemplo de um operador é o operador de atribuição, identificada pela produção <operador>'='. Este operador requer que o argumento da esquerda é avaliada como uma string cujo conteúdo é compatível com a produção <token>. O conteúdo de uma string é definida como a cadeia de caracteres entre aspas encerram. O operador de igualdade faz com que a variável cujo nome é o <token> igual ao teor do argumento esquerda para ser atribuído um valor igual ao resultado da avaliação do argumento do lado direito. Este valor é também o resultado da avaliação da expressão do operador.

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

[000410]Em uma modalidade da presente invenção, o identificador de um arquivo pode ser obtido através da avaliação de um arquivo de regra construção identificador de acordo com a regra acima com um conjunto específico de variáveis de entrada que identificam o arquivo pretendido. Um exemplo de uma variável de entrada é a variável com o "index" nome e igual valor para o índice numérico do arquivo dentro da apresentação. Outro exemplo de uma variável de entrada é a variável com "bitrate" nome e o valor igual à taxa de bits média da versão necessária da apresentação.

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

[000412]Como estará claro para os técnicos na área após a leitura desta descrição, numerosas variações do método acima são possíveis. Por exemplo, não todas as funções e os operadores descritos acima podem ser fornecidas ou funções adicionais ou os operadores podem ser fornecidas.

Regras de construção de URL e de temporização

[000413]Esta seção fornece regras de construção básicos URI para atribuir um URI arquivo ou segmento, bem como um horário de início de cada segmento dentro de uma representação e apresentação de mídia.

[000414]Para esta cláusula a disponibilidade de uma descrição apresentação de mídia no cliente é presumida.

[000415]Vamos supor que o cliente HTTP streaming é jogar fora de mídia que é baixado dentro de uma apresentação multimídia. O tempo de cliente HTTP de apresentação real pode ser definida como a onde o tempo de apresentação é relativo ao início da apresentação. Na inicialização, o tempo t = 0 apresentação pode ser assumida.

[000416]Em qualquer ponto t, o cliente HTTP podem baixar quaisquer dados com tempo de reprodução TP (também em relação ao início da apresentação), no máximo, à frente da MaximumClientPreBufferTime t real apresentação do tempo e os dados que são necessários devido a uma interação do utilizador , por exemplo procurar, avançar, etc Em algumas concretizações o MaximumClientPreBufferTime não pode mesmo ser especificado no sentido de que um cliente pode transferir dados à frente da tP atual tempo de jogo sem restrições.

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

[000418]O processo básico na prestação dos serviços de streaming pode ser a descarga de dados através da geração de solicitações apropriadas para download de arquivos inteiros/segmentos ou subconjunto de arquivos e segmentos, por exemplo, usando solicitações HTTP GET ou HTTP parcial solicitações GET. Esta descrição trata de como acessar os dados para um jogo específico tP tempo, mas geralmente o cliente pode fazer download de dados para um intervalo de tempo maior do tempo de jogo para evitar pedidos de ineficientes. O cliente HTTP pode minimizar o número/freqüência de solicitações HTTP na prestação do serviço de streaming.

[000419]Para acessar dados de mídia no tempo de reprodução tP ou, pelo menos próximos a tP em uma representação específica, o cliente determina o URL para o arquivo que contém esse instante da reprodução e além disso determina o intervalo de bytes no arquivo para acessar este instante de reprodução.

[000420]A descrição de apresentação de mídia pode atribuir um id de representação, r, para cada representação, por exemplo pelo uso do atributo RepresentationID. Em outras palavras, o conteúdo do MPD, quando escrito pelo sistema de ingestão ou quando lido pelo cliente, será interpretada tal que há uma atribuição. Para transferir dados para um tempo de reprodução específico tP para uma representação específica com identificação r, o cliente pode construir um URI apropriado para um arquivo.

[000421]A descrição de apresentação de mídia pode atribuir para cada arquivo ou segmento de cada representação r os seguintes atributos: (a) um número de seqüência i dentro do arquivo de representação r, com i = 1, 2,..., Nr; (b) a hora de início relativa do arquivo com representação de ID r e arquivo de índice i relativo ao tempo de apresentação, definido como ts(r,i); (c) o arquivo URI para o segmento/arquivo com índice de r e arquivo de identificação de representação, denotado como FileURI (r, i).

[000422]Em uma modalidade a hora de início do arquivo e os URIs dos arquivos podem ser fornecidos explicitamente para uma representação. Em outra modalidade, uma lista de arquivo URIs pode ser provida, em que cada arquivo URI obtém explicitamente o índice i de acordo com a posição na lista e o instante de início do segmento é derivado como a soma de todas as durações de segmento para os segmentos 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 com conhecimento na área de matemática básica pode utilizar outros métodos para derivar uma metodologia para facilmente derivar o tempo/instante de início de um único elemento ou atributo e o índice posição do arquivo URI na representação.

[000423]Caso seja provida uma regra de construção dinâmica no MPD, então o instante de início de cada arquivo e cada URI de arquivo podem ser construídos dinamicamente pelo uso de uma regra de construção, do índice do arquivo requisitado e potencialmente alguns parâmetros adicionais fornecidos na descrição de apresentação da mídia. As informações podem ser fornecidas por exemplo nos atributos e elementos do MPD, tais como FileURIPattem e FileInfoDynamic. O FileURIPattem fornece informações sobre como construir URIs com base no número de seqüência do arquivo de índice i e o r de ID de representação. O FileURIFormat é calculado por: FileURIFormat = sprintf ("%s%s%s%s%s.%s", BaseURI, BaseFileName, RepresentationIDFormat, SeparatorFormat, FileSequenceIDFormat, FileExtension); e o FileURI(r,i) é construído por: FileURI(r,i) = sprintf (FileURIFormat, r, i);

[000424]O instante de início relativo ts(r,i) para cada segmento/arquivo pode ser derivado por algum atributo contido no MPD descrevendo a duração dos segmentos nessa representação, por exemplo, o atributo FileInfoDynamic. O MPD também pode conter uma seqüência de atributos de FileInfoDynamic que é global para todas as representações da apresentação de mídia ou no mínimo para todas as representações em um período da mesma forma conforme especificado acima. Se dados de mídia para um específico tP, tempo de reprodução, na representação r, são solicitados, o índice correspondente i(r, tP) pode ser derivado como i(r, tp) tal que o tempo de reprodução deste índice fique no intervalo entre a hora de início do ts(r, i(r e tP)) e ts (r, i(r e tP) + 1). O acesso de segmento pode ser ainda mais restrito para os casos acima, por exemplo, o segmento não está acessível.

[000425]Para acessar o instante de reprodução tP exato, uma vez que o índice e o URI do segmento correspondente sejam obtidos, depende do formato de segmento real. Este exemplo assume que os segmentos de mídia têm uma linha de hora local que começa em 0 sem perda de generalidade. Para aceder e apresentar os dados em tempo/instante de reprodução tP, o cliente pode baixar os dados correspondentes para a hora local do arquivo/segmento que pode ser acessado através do URI FileURI(r,i) com i = i(r, tp).

[000426]De um modo geral, os clientes podem baixar o arquivo inteiro e podem então acessar o tP - instante de reprodução. No entanto, não necessariamente todas as informações do arquivo 3GP são necessárias para download, dado que o arquivo 3GP fornece estruturas para mapear o timing local para intervalos de bytes. Por conseguinte, apenas os intervalos de bytes específicos para acessar tP - tempo de reprodução - podem ser suficientes para reproduzir a mídia, desde que estejam disponíveis informações suficientes de acesso aleatório. Também podem ser prestadas informações suficientes sobre estrutura e mapeamento do intervalo de bytes e o timing local do segmento de mídia na parte inicial do segmento, por exemplo usando um índice de segmento. Tendo acesso ao início, por exemplo 1200 bytes, do segmento, o cliente pode ter informações suficientes para acessar diretamente o intervalo de bytes necessário para o instante de reprodução TP.

[000427]Um outro exemplo supõe que o índice de segmento, possivelmente especificado como a caixa/box “tidx” como abaixo, pode ser utilizado para identificar os deslocamentos/offsets de bytes do fragmento ou fragmentos necessários. As solicitações GET parciais podem ser formadas para o fragmento ou fragmentos desejados. Existem outras alternativas, por exemplo o cliente pode emitir uma solicitação padrão para o arquivo e cancelar esta quando receber a primeira caixa de "tidx".

Pesquisa/Busca

[000428]Um cliente pode tentar procurar um instante de apresentação específico tp em uma representação. Baseado no MPD, o cliente tem acesso ao instante/tempo de início do segmento de mídia e ao URL de cada segmento de mídia na representação. O cliente pode obter o índice de segmento, segment_index do segmento com maior probabilidade de conter amostras de mídia para o instante de apresentação tp como o índice máximo de segmento i para o qual o tS(r,i) de hora de início é menor ou igual ao tempo de apresentação tp ou seja segment_index = max{iltS(r,i) <tp}. O URL do segmento é obtido como FileURI(r,i).

[000429]Note-se que as informações de temporização/timing no MPD podem ser aproximadas devido a questões relacionadas com a colocação dos pontos de acesso aleatório, alinhamento de faixas de mídia e deriva de timing de mídia. Como resultado, o segmento identificado pelo procedimento acima pode começar em um momento um pouco após tp e os dados de mídia para o instante de apresentação tp podem estar no segmento de mídia anterior. No caso de busca, o tempo de busca pode ser atualizado para igualar o instante da primeira amostra do arquivo recuperado, ou do arquivo anterior que pode ser recuperado em seu lugar. No entanto, note-se que durante a reprodução contínua, incluindo os casos onde há uma comutação entre representações/versões alternativas, os dados de mídia para o tempo entre o tp e o início do segmento recuperado estarão disponíveis.

[000430]Para pesquisa acurada de um instante de apresentação tp, o cliente de fluxo contínuo de HTTP precisa acessar um ponto de acesso aleatório (RAP). Para determinar o ponto de acesso aleatório em um segmento de mídia de fluxo contínuo de HTTP adaptável 3GPP, o cliente pode, por exemplo, usar as informações na caixa “tidx” ou “sidx”, caso presentes, para localizar os pontos de acesso aleatório e o correspondente tempo de apresentação da apresentação de mídia. Nos casos em que um segmento é um fragmento de filme 3GPP, também é possível para o cliente usar informações dentro dos boxes “moor” e “mdat”, por exemplo para localizar RAPs e obter o necessário tempo de apresentação dos dados no fragmento de filme e o instante de início de segmento do MPD. Se nenhum RAP com tempo de apresentação antes do tp de tempo apresentação solicitada estiver disponível, o cliente pode acessar o segmento anterior, ou pode usar apenas o primeiro ponto de acesso aleatório como o resultado de busca. Quando segmentos de mídia começam com um RAP, estes procedimentos são simples.

[000431]Note-se também que não necessariamente todas as informações do segmento de mídia precisam ser baixadas para acessar o tempo de apresentação tp. O cliente pode, por exemplo, inicialmente solicitar a caixa “tidx” ou “sidx” desde o início do segmento de mídia usando solicitações de intervalo de bytes. Usando as caixas tidx ou sidx, o sincronismo/timing de segmento pode ser mapeado para intervalos de bytes do segmento. Pelo uso contínuo de solicitações HTTP parciais, somente as partes relevantes do segmento de mídia precisam ser acessadas, para uma melhor experiência do usuário e baixos retardos de inicialização.

Geração de Lista de Segmentos

[000432]Tal como foi aqui descrito, deve agora estar claro como implementar um cliente de fluxo contínuo de HTTP simples, que usa as informações fornecidas pelo MPD para criar uma lista de segmentos para uma representação que tem uma duração assinalada de segmento aproximada de dur. Em algumas modalidades, o cliente pode atribuir aos segmentos de mídia dentro de uma representação índices consecutivos i = 1, 2, 3,..., isto é, ao primeiro segmento de mídia é atribuído o índice i = 1, a segundo segmento de mídia é atribuído o índice i = 2 e assim por diante. Então, à lista de segmentos de mídia com índices de segmento i é atribuído o startTime[i] e o URL[i] é gerado, por exemplo como se segue. Em primeiro lugar, o índice i é definido como 1. A hora de início do primeiro segmento de mídia é obtida como 0, startTime[1] = 0. O URL do segmento de mídia i, URL [i], é obtido como FileURI(r, i). O processo prossegue para todos os segmentos de mídia descritos com índice i e o startTime[i] do segmento de mídia é obtido como (i- l)*dur e o URL[i] é obtido como FileURI(r, i).

Solicitações HTTP/TCP Simultâneas

[000433]Uma preocupação em um sistema de streaming de solicitação de bloco é um desejo de sempre pedir os blocos de mais alta qualidade que podem ser completamente recebidos a tempo para reprodução. No entanto, a taxa de chegada de dados não pode ser conhecida com antecedência e assim pode acontecer que um bloco solicitado não chega a tempo de ser reproduzido. Isso resulta em uma necessidade de pausar a reprodução de mídia, o que resulta em uma experiência de usuário ruim. Este problema pode ser atenuado por algoritmos de cliente que assumem uma abordagem conservadora para a seleção de blocos a solicitar, solicitando blocos de qualidade inferior (e portanto de menor tamanho, que são mais propensos a ser recebidos em tempo, mesmo se a taxa de chegada de dados cai durante a recepção do bloco). No entanto esta abordagem conservadora tem a desvantagem de entregar possivelmente uma reprodução de qualidade inferior para o usuário ou dispositivo de destino, o que também é equivalente a uma experiência de usuário ruim. O problema pode ser ampliado quando várias conexões HTTP são usadas ao mesmo tempo para baixar blocos diferentes, conforme descrito a seguir, uma vez que recursos de rede disponíveis são compartilhados entre ligações e, portanto, estão sendo usados simultaneamente para blocos com diferentes tempos de reprodução.

[000434]Pode ser vantajoso para o cliente emitir solicitações para múltiplos blocos simultaneamente, em que, neste contexto, “simultaneamente” significa que as respostas às solicitações estão ocorrendo com sobreposição de intervalos de tempo, não sendo necessariamente o caso em que as solicitações são feitas precisamente, ou até mesmo aproximadamente, ao mesmo tempo. No caso do protocolo HTTP, essa abordagem pode melhorar a utilização da largura de banda disponível devido ao comportamento do protocolo TCP (que é bem conhecido). Isso pode ser especialmente importante para melhorar o tempo de zapping de conteúdo, uma vez que quando um novo conteúdo é solicitado pela primeira vez as conexões HTTP/TCP correspondentes através das quais são solicitados dados para os blocos podem ser lentas para inicializar, e assim usar várias conexões HTTP/TCP neste momento pode acelerar drasticamente o tempo de entrega de dados dos blocos de primeiros. No entanto, o solicitar blocos diferentes ou fragmentos em diferentes conexões HTTP/TCP também pode levar à degradação do desempenho, dado que as solicitações para os blocos que estão para ser reproduzidos pela primeira vez estão competindo com os pedidos para os blocos subseqüentes, os downloads HTTP/TCP concomitantes variam muito na sua velocidade de entrega e, portanto, o tempo de conclusão da solicitação pode ser altamente variável, geralmente não é possível controlar quais downloads HTTP/TCP serão completados rapidamente e qual será mais lento e, portanto, é provável que pelo menos algumas vezes os downloads HTTP/TCP do primeiros blocos serão os últimos a se completar, levando assim a tempos de zapping de canal grandes e variáveis.

[000435]Vamos supor que cada bloco ou o fragmento de um segmento seja baixado através de uma conexão HTTP/TCP separada e que o número de conexões paralelas é n e a duração de reprodução de cada bloco é de t segundos, sendo que a taxa de fluxo contínuo de conteúdo associado com o segmento é S. Quando o cliente, pela primeira vez, começa a reproduzir o conteúdo, as requisições podem ser emitidas para os primeiros n blocos, representando n*t segundos de dados de mídia.

[000436]Como sabem os técnicos na área, há uma grande variação na taxa de dados de conexões TCP. No entanto, para simplificar esta discussão, vamos supor que o ideal é que todas as conexões avancem em paralelo, de tal forma que o primeiro bloco será completamente recebido aproximadamente no mesmo tempo que os outros n-1 blocos requisitados. Para simplificar ainda mais a discussão, vamos supor que a largura de banda total utilizada pelas n conexões de download seja fixa e com um valor de b para toda a duração do download, e que a taxa de streaming s é constante por toda a representação. Vamos supor ainda que a estrutura de dados de mídia é tal que reprodução de um bloco pode ser feita quando o bloco inteiro está disponível no cliente, ou seja, reprodução de um bloco só pode iniciar depois de todo o bloco ser recebido, por exemplo devido à estrutura da codificação de vídeo subjacente, ou porque criptografia/codificação está sendo empregada para criptografar cada fragmento ou bloco separadamente e, portanto, o fragmento inteiro ou bloco deve ser recebido antes que ele possa ser decodificado. Dessa forma, para simplificar a discussão abaixo, podemos supor que um bloco inteiro deve ser recebido antes que qualquer um dos blocos possa ser reproduzido. Portanto, o tempo necessário antes que o primeiro bloco chegue e possa ser reproduzido é de aproximadamente n*t*S/b.

[000437]Uma vez que é desejável minimizar o tempo de zapping de conteúdo, é portanto desejável minimizar n*t*S/b. O valor de t pode ser determinado por fatores tais como a estrutura subjacente de codificação de vídeo e como são utilizados os métodos de ingestão; assim t pode ser razoavelmente pequeno, mas valores muito pequenos de t levam a um mapa de segmentos excessivamente complicado e possivelmente podem ser incompatíveis com uma eficiente codificação e decodificação de vídeo, se usadas. O valor de n pode também afetar o valor de B, ou seja, B pode ser maior para um grande número n de conexões e portanto, reduzir o número de conexões, n, tem o efeito colateral negativo potencial de reduzir a quantidade de largura de banda disponível que é utilizada, B, e assim pode não ser eficaz na consecução do 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 idealmente s devem ser tão próximo de b quanto possível para maximizar a qualidade de reprodução dos meios de comunicação/mídia para as condições de rede fornecidas. Assim, para simplificar esta discussão, vamos supor que s é aproximadamente igual a b. Portanto, o tempo de zapping do canal é proporcional a n*t. Assim, utilizar mais conexões para baixar diferentes fragmentos pode degradar o tempo de zapping de canal caso a largura de banda total utilizada pelas conexões seja sublinearmente proporcional ao número de conexões, o que é normalmente o caso.

[000438]Como exemplo, vamos supor 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. Suponhamos que seja escolhida a representação com S = 700 Kbps. Então, com n = 1 o tempo de download para o primeiro bloco é 1 * 700/500 = 1,4 segundos, com n = 2 o tempo de download para o primeiro bloco é 2 * 700/700 = 2 segundos e com n = 3 o tempo de download para o primeiro bloco é 3 * 700/800 = 2.625 segundos. Além disso, a medida que o número de conexões aumenta a variabilidade nas velocidades de download individual das conexões é susceptível de aumentar (embora mesmo com uma conexão há provavelmente alguma variabilidade significativa). Assim, neste exemplo, o tempo de zapping de canal e a variabilidade no tempo de zapping de canal aumenta à medida que o número de conexões aumenta. Intuitivamente, os blocos que estão sendo entregues têm prioridades diferentes, ou seja, o primeiro bloco tem o prazo de entrega mais cedo, o segundo bloco tem a segunda mais antiga deadline e assim por diante. Considerando que as conexões de download através das quais os blocos estão sendo entregues estão competindo por recursos de rede durante a entrega, os blocos com os primeiros prazos tornam-se mais atrasados a medida que mais blocos concorrentes são solicitados. Por outro lado, mesmo neste caso, em última análise, usar mais de uma conexão de transferência permite suportar de uma forma sustentável maior taxa de fluxo contínuo, por exemplo, com três conexões uma taxa de transmissão de até 800 Kbps pode ser suportada neste exemplo, enquanto que apenas um fluxo de 500 Kbps pode ser apoiado com uma conexão.

[000439]Na prática, como observado acima, a taxa de dados de uma conexão pode ser altamente variável tanto dentro da mesma conexão ao longo do tempo e entre conexões e, em conseqüência, os n blocos solicitados geralmente não são concluídos ao mesmo tempo e, na verdade, comumente pode ser o caso de que um bloco pode ser concluído na metade do tempo de outro bloco. Este efeito resulta em um comportamento imprevisível, já que em alguns casos o primeiro bloco pode ser concluído muito mais cedo do que outros blocos e em outros casos o primeiro bloco pode ser concluído mais tarde do que outros blocos, e assim o início da reprodução pode, em alguns casos, ocorrer de forma relativamente rápida e em outros casos pode ser de ocorrência lenta. Esse comportamento imprevisível pode ser frustrante para o usuário e, portanto, pode ser considerado uma experiência de usuário ruim.

[000440]O que se necessita, portanto, são métodos em que múltiplas conexões TCP possam ser utilizadas para melhorar o tempo de zapping de canal e a variabilidade no tempo de zapping de canal, concomitantemente dando suporte a uma taxa de streaming de boa qualidade possível. O que é necessário também, são métodos para permitir o compartilhamento da largura de banda disponível alocada para cada bloco, sendo ajustada conforme se aproxima a hora de reprodução de um bloco, para que, se necessário, um percentual maior de largura de banda disponível possa ser alocado para o bloco com o tempo de reprodução mais próximo.

Requisição HTTP/TCP Cooperativa

[000441] Serão agora descritos métodos de uso de solicitações HTTP/TCP simultâneas em uma forma cooperativa. Um receptor pode empregar várias solicitações HTTP/TCP cooperativas simultâneas, usando por exemplo uma pluralidade de solicitações de intervalo de bytes HTTP, em que cada um de tais pedidos é para uma parte de um fragmento em um segmento de origem, ou a totalidade de um fragmento de um segmento de origem, ou uma parte de um fragmento de reparação, ou para todo um fragmento de reparação de um segmento de reparação.

[000442]As vantagens das requisições HTTP/TCP cooperativas em conjunto com o uso de dados de reparo FEC podem ser especialmente importantes para 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 acabaram de ser iniciadas ou tenham ficado ociosas por algum período de tempo, caso em que a janela de congestionamento, cwnd, está no seu valor mínimo para as conexões, e assim a velocidade de entrega dessas conexões TCP tomará vários tempos de ida e volta (RTTs) para se elevar, e haverá alta variabilidade nas velocidades de entrega através das diferentes conexões TCP durante este tempo de aceleração.

[000443] Será agora descrita uma visão geral do método “não-FEC” ou “sem-FEC”, que é um método de solicitação HTTP/TCP cooperativo em que somente os dados de mídia de blocos de origem são solicitados usando-se várias conexões HTTP/TCP simultâneas, ou seja, não há dados de reparação FEC sendo solicitados. Com o método de não-FEC, porções do mesmo fragmento são solicitadas através de conexões diferentes, por exemplo usando solicitações HTTP de intervalos de bytes para porções do fragmento, por exemplo cada solicitação de intervalo de bytes HTTP é uma parte do intervalo de byte indicado no mapa do segmento para o fragmento. Pode ocorrer o caso em que uma requisição individual HTTP/TCP acelere sua velocidade de entrega para utilizar totalmente a largura de banda disponível ao longo de vários tempos de ida e volta e, assim, há um período de tempo relativamente longo em que a velocidade de entrega será menor que a largura de banda disponível e, assim, se uma única conexão HTTP/TCP for usada para fazer o download por exemplo do primeiro fragmento de um conteúdo para ser reproduzido, o tempo de zapping de canal poderia ser grande. Usando o método de não-FEC, baixar partes diferentes do mesmo fragmento por diferentes conexões HTTP/TCP pode reduzir significativamente o tempo de zapping de canal.

[000444] Será agora descrita uma visão geral do método FEC, que é um método de solicitação HTTP/TCP cooperativo em que dados de mídia de um segmento de origem e dados de reparo FEC gerados a partir da mídia de dados são solicitados usando-se várias conexões HTTP/TCP simultâneas. Com o método FEC, porções do mesmo fragmento e dados de reparo FEC gerados a partir desse fragmento são solicitadas através de conexões diferentes, usando requisições de intervalo de bytes HTTP para porções do fragmento, e assim, por exemplo, cada solicitação de intervalo de bytes HTTP é uma parte do intervalo de byte indicado no mapa do segmento para o fragmento. Pode ocorrer que uma requisição individual HTTP/TCP acelere a velocidade de entrega para utilizar totalmente a largura de banda disponível ao longo de vários tempos de ida e volta e, portanto, há um período de tempo relativamente longo onde a velocidade de entrega é menor que a largura de banda disponível e, assim, se uma única conexão HTTP/TCP for usada para fazer o download por exemplo no primeiro fragmento de um conteúdo para ser reproduzido, o tempo de zapping de canal poderia ser grande. Usar o método FEC tem as mesmas vantagens que o método não-FEC e tem a vantagem adicional de que nem todos os dados solicitados precisam chegar antes que o fragmento possa ser recuperado, reduzindo assim ainda mais o tempo de zapping de canal e a variabilidade no tempo de zapping de canal. Fazendo solicitações através de diferentes conexões de TCP, e super-requisitando por também solicitar dados de reparação FEC através pelo menos uma das conexões, a quantidade de tempo necessária para entregar uma quantidade suficiente de dados para, por exemplo, recuperar o primeiro fragmento solicitado que permite iniciar a reprodução de mídia iniciar, pode ser grandemente reduzida e tornada muito mais consistente do que se não fossem usadas as conexões TCP cooperativas e dados de reparo FEC.

[000445]As Figuras 24(a) a (e) apresentam um exemplo de flutuações da taxa de entrega de 5 conexões TCP em execução através do mesmo link para o mesmo cliente do mesmo servidor web HTTP de uma rede EV-DO (Emulated Evolution Data Optimized). Nas Figuras 24(a) a (e) o eixo dos x indica o tempo em segundos e o eixo dos y a taxa em que os bits são recebidas no cliente através de cada uma das 5 conexões TCP, medida ao longo de intervalos de 1 segundo, para cada conexão. Nessa emulação específica, havia 12 conexões TCP em marcha total através deste link, e assim a rede estava relativamente carregada durante o tempo mostrado, o que poderia ser típico quando mais de um cliente está baixando em streaming dentro da mesma célula de uma rede móvel. Note-se que, embora as taxas de entrega estejam um pouco correlacionadas ao longo do tempo, há grande diferença nas taxas de entrega das 5 conexões em muitos pontos no tempo.

[000446]A Figura 25 mostra uma possível estrutura de solicitação/requisição para um fragmento que possui 250.000 bits de tamanho (aproximadamente 31,25 kilobytes), em que há 4 requisições HTTP de intervalos de bytes feitas em paralelo para diferentes partes do fragmento, ou seja, a primeira conexão de HTTP solicita os primeiros 50.000 bits, a segunda conexão HTTP solicita os seguintes 50.000 bits, a terceira conexão HTTP solicita os seguintes 50.000 bits, e a quarta conexão HTTP solicita os seguintes 50.000 bits. Se FEC não for usada, ou seja, o método não-FEC então estes são os únicos 4 pedidos para o fragmento de neste exemplo. Se FEC é usado, ou seja, o método FEC, então neste exemplo existe uma conexão HTTP adicional que solicita um adicional de 50.000 bits de dados de reparo FEC de um segmento de reparação gerado a partir do fragmento.

[000447]A Figura 26 é uma ampliação do primeiro par de segundos das 5 conexões TCP mostrados nas Figuras 24(a) a (e) em que, na Figura 26 o eixo dos x mostra o tempo em intervalos de 100 milissegundos, e o eixo dos y mostra a taxa na qual bits são recebidos no cliente através de cada uma das 5 conexões TCP, medido ao longo de intervalos de 100 milissegundos. Uma linha mostra a quantia total de bits que foi recebida pelo cliente para o fragmento das primeiras 4 conexões HTTP (excluindo a conexão HTTP sobre a qual os dados FEC são solicitados), isto é, o que é recebido usando-se o método não-FEC. Outra linha mostra a quantia total de bits que foi recebida pelo cliente para o fragmento por todas as 5 conexões HTTP (incluindo a conexão HTTP sobre qual os dados FEC são requisitados), ou seja o que chega usando-se o método FEC. Para o método FEC, presume- se que o fragmento pode ser decodificado com FEC a partir da recepção de quaisquer 200.000 bits dentre os 250.000 bits solicitados, o que pode ser realizado se por exemplo um código FEC Reed-Solomon for usado, e que pode ser essencialmente efetuado caso, por exemplo, seja usado o código RaptorQ, descrito em Luby IV. Para o método FEC neste exemplo, são recebidos dados suficientes para recuperar o fragmento usando decodificação FEC após 1 segundo, permitindo um tempo de zapping de canal de 1 segundo (supondo que os dados de fragmentos subseqüentes podem ser requisitados e recebidos antes o primeiro fragmento é totalmente reproduzido). Para o método de não-FEC neste exemplo, todos os dados das 4 solicitações devem ser recebidos antes que o fragmento possa ser recuperado, o que ocorre após 1,7 segundo, conduzindo a um tempo de zapping de canal de 1,7 segundos. Assim, no exemplo mostrado na Fig. 26, o método não-FEC é 70% pior em termos de tempo de zapping de canal do que o método FEC. Uma das razões para a vantagem demonstrada pelo método FEC neste exemplo é que, para o método FEC, a recepção de quaisquer 80% dos dados solicitados permite a recuperação do fragmento, enquanto que para o método não-FEC, a recepção de 100% dos dados solicitados é necessária. Assim, o método não-FEC terá que aguardar a conexão TCP mais lenta para concluir a entrega e, por causa das variações naturais da taxa de entrega TCP há de ocorrer ampla variação da velocidade de entrega da conexão TCP mais lento em comparação com uma conexão TCP média. Com o método FEC neste exemplo, uma conexão lenta TCP não determina quando o fragmento é recuperável. Em vez disso, para o método FEC, a entrega de dados suficientes é muito mais uma função da taxa de entrega TCP média do que a taxa de entrega TCP no pior caso.

[000448]Existem muitas variações do método não-FEC e do método FEC descritos acima. Como exemplo, as solicitações HTTP/TCP cooperativas podem ser utilizadas apenas para os primeiros poucos fragmentos após ter ocorrido um zapping de canal, e posteriormente apenas uma única solicitação HTTP/TCP é usada para fazer o download de mais fragmentos, múltiplos fragmentos, ou segmentos inteiros. Como outro exemplo, o número de conexões HTTP/TCP cooperativas usado pode ser uma função da urgência com que os fragmentos estão sendo solicitados, ou seja, quão iminente está o instante de reprodução desses fragmentos e as condições de rede atuais.

[000449]Em algumas variações, uma pluralidade de conexões HTTP pode ser usada para solicitar dados de reparação de segmentos de reparação. Em outras variações, diferentes quantidades de dados podem ser solicitadas através de diferentes conexões HTTP, por exemplo dependendo do tamanho atual do buffer de mídia e da taxa de recepção de dados no cliente. Em outra variação, as representações de origem não são independentes umas das outras, mas em vez disso representam uma mídia em camadas de codificação, onde, por exemplo, uma representação de fonte aprimorada pode depender de uma representação de fonte base. Neste caso, pode ser uma representação de reparação correspondente à representação de base fonte e outra representação de reparação correspondente à combinação de representações de origem de base e melhorada.

[000450]Elementos globais adicionais se somam às vantagens que se pode obter pelos métodos divulgados acima. Como exemplo, o número de conexões de HTTP usado pode variar dependendo da quantidade atual de mídia no buffer de mídia e/ou da taxa de recepção para o buffer de mídia. Requisições HTTP cooperativas usando FEC, isto é, o método FEC descrito acima, e variantes desse método, podem ser fortemente utilizadas quando o buffer de mídia estiver relativamente vazio. Como exemplo, são feitas mais solicitações HTTP cooperativas em paralelo para diferentes partes do primeiro fragmento, solicitando todo o fragmento de origem e uma fração relativamente grande de dados de reparo do fragmento correspondente de reparação e, em seguida, fazer a transição para um número reduzido de solicitações HTTP simultâneas, solicitando maiores porções de dados de mídia por pedido e solicitando uma fração menor de dados de reparação, por exemplo, passando para 1, 2 ou 3 solicitações HTTP simultâneas, passando a fazer solicitações de fragmentos completos ou vários fragmentos consecutivos por pedido, e passando para deixar de solicitar dados de reparação a medida que o buffer de mídia cresce.

[000451]Como outro exemplo, a quantidade de dados de reparo FEC pode variar como uma função do tamanho do buffer de mídia, ou seja, quando o buffer de mídia é pequeno, então mais dados de reparo FEC poderão ser solicitados, e a medida que o buffer de mídia cresce, então a quantidade de dados de reparo FEC solicitadas pode diminuir e em algum momento quando o buffer de mídia está suficientemente grande, então não podem ser requisitados dados de reparo FEC, somente dados do segmento de origem das representações de origem. Os benefícios dessas técnicas avançados é que eles podem permitir tempos de zapping de canal mais rápidos e consistentes, bem como mais resistência contra potenciais irregularidades e interrupções de mídia, minimizando ao mesmo tempo a quantidade de amplitude de banda adicional usada para além do montante que seria consumido apenas pelo fornecimento dos meios de comunicação nos segmentos de fonte reduzindo tanto o tráfego de mensagens de solicitação e dados de reparo FEC, ao mesmo tempo permitindo o suporte das taxas de mídia mais altas para dadas condições de rede.

Aprimoramentos Adicionais Quando se Utilizam Conexões HTTP Simultâneas

[000452]Uma solicitação HTTP/TCP pode ser abandonada caso seja encontrada uma condição adequada e outro pedido HTTP/TCP pode ser feito para baixar os dados que podem substituir os dados solicitados no pedido abandonado, em que a segunda solicitação HTTP/TCP pode solicitar exatamente os mesmos dados como no pedido original, por exemplo, dados de origem; ou uma sobreposição de dados, por exemplo, alguns da mesma fonte de dados e dados de reparação que não haviam sido solicitados na primeira solicitação; ou dados completamente desconexos, por exemplo, dados de reparação que não haviam sido solicitados na primeira solicitação. Um exemplo de uma condição adequada é aquele em que uma solicitação falha devido a falta de resposta da infra-estrutura de servidor de bloco (BSI) dentro de um prazo fornecido ou uma falha no estabelecimento de uma conexão de transporte com o BSI ou recebimento de uma mensagem de falha explícita de servidor ou outra condição de falha.

[000453]Outro exemplo de uma condição adequada é a de que a recepção dos dados está andando de forma anormalmente lenta, de acordo com uma comparação de medida da velocidade de conexão (taxa de chegada de dados em resposta ao pedido em questão) com a velocidade de conexão esperada ou uma estimativa da velocidade de conexão necessária para receber a resposta antes do tempo de reprodução dos dados de mídia neles contidos, ou outro momento dependente de tal instante.

[000454]Tal abordagem apresenta a vantagem no caso em que o BSI, algumas vezes, apresenta falhas ou mau desempenho. Neste caso, a abordagem acima aumenta a probabilidade de que o cliente possa continuar uma reprodução confiável dos dados de mídia apesar de falhas ou mau desempenho dentro do BSI. Note-se que em alguns casos pode haver vantagens em projetar o BSI de tal forma que ele apresente tais falhas ou um fraco desempenho em certas ocasiões, por exemplo tal projeto pode ter um custo menor do que uma concepção alternativa que não apresente tais falhas ou mau desempenho ou que apresenta estas menos freqüentemente. Neste caso o método descrito aqui ainda tem vantagem pelo fato de que ele permite a utilização de um esquema de custo inferior para o BSI sem uma conseqüente degradação na experiência do usuário.

[000455]Em outra modalidade, o número de pedidos emitidos para dados correspondentes a um determinado bloco pode ser dependente de se é atendida uma condição adequada com relação ao bloco. Se a condição não for atendida então o cliente pode ser restringido para efetuar novas solicitações para o bloco, caso a conclusão com êxito de todas as solicitações de dados atualmente incompletos para o bloco permitisse a recuperação do bloco com alta probabilidade. Se a condição for atendida, então um maior número de solicitações para o bloco pode ser emitido, ou seja, a limitação acima não se aplica. Um exemplo de uma condição adequada é a de que o tempo até a hora agendada para reprodução do bloco, ou outro instante dependente deste tempo, fica abaixo de um limiar fornecido. Este método apresenta vantagem pois pedidos adicionais de dados para um bloco são emitidos quando a recepção do bloco torna- se mais urgente, porque o momento de reprodução dos dados de mídia que incluem o bloco está próximo. No caso de protocolos de transporte comuns, como o HTTP/TCP, essas solicitações adicionais têm o efeito de aumentar a percentagem de largura de banda disponível dedicada para dados que contribuem para a recepção do bloco em questão. Isso reduz o tempo necessário para a recepção de dados suficientes para recuperar o bloco, para completar e, por conseguinte, reduz a probabilidade de que o bloco não pode ser recuperado antes do tempo agendado para reprodução dos dados de mídia que incluem o bloco. Como descrito acima, se o bloco não pode ser recuperado antes do tempo agendado para reprodução dos dados de mídia que incluem o bloco, a reprodução pode pausar, resultando em uma experiência pobre para o usuário e, portanto, o método descrito aqui vantajosamente reduz a probabilidade dessa experiência de usuário ruim.

[000456]Deve ficar claro que em toda este relatório descritivo referências ao instante agendado de reprodução de um bloco se referem ao tempo em que os dados de mídia codificada compreendendo o bloco primeiro estejam disponíveis no cliente para obtenção da reprodução da apresentação sem pausa. Como será claro para os técnicos na área de sistemas de apresentação de mídia, isto ocorre na prática um pouco antes da hora real do aparecimento dos mídia que compreendem o bloco em transdutores físicos usados para reprodução (tela, alto-falantes, etc.) dado que várias funções de transformação talvez precisem ser aplicadas aos dados de mídia que incluem o bloco para efetuar a reprodução real de tal bloco e essas funções podem exigir uma certa quantidade de tempo para se completar. Como exemplo, dados de mídia geralmente são transportados na forma compactada e uma transformação de descompressão pode ser aplicada.

Métodos para gerar estruturas de arquivos que suportem métodos de HTTP/FEC cooperativos

[000457] Será agora descrita uma modalidade para gerar uma estrutura de arquivo que pode ser usada vantajosamente por um cliente que emprega métodos HTTP/FEC cooperativos. Na presente modalidade, para cada fonte de segmento existe um segmento de reparação correspondente gerado da forma que se segue. O parâmetro R indica, em média, quantos dados de reparação FEC são gerados para os dados de origem/fonte nos segmentos de origem. Como exemplo, R = 0,33 indica que se um segmento de origem contiver 1.000 kilobytes de dados, o segmento de reparação correspondente contém aproximadamente 330 kilobytes de dados de reparo. O parâmetro S indica o tamanho do símbolo em bytes usado para codificação e decodificação FEC. Como exemplo, S = 64 indica que os dados de origem e os dados de reparação compreendem símbolos de 64 bytes para cada, para codificação e decodificação FEC.

[000458]O segmento de reparação pode ser gerado para um segmento de origem da seguinte forma. Cada fragmento do segmento de origem é considerado como um bloco de origem para fins de codificação FEC, e assim cada fragmento é tratado como uma seqüência de símbolos de origem de um bloco de origem da qual são gerados símbolos de reparo. O número de símbolos de reparação gerados no total para os primeiros i fragmentos é calculado como TNRS(i) = ceiling(R*B(i)/S), onde ceiling(x) é a função que gera o menor número inteiro com um valor que seja pelo menos x. Dessa forma, o número de símbolos de reparação gerados para o fragmento i é NRS(i) = TNRS(i) - TNRS (i-1).

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

[000460]Note-se que pela definição do número de símbolos de reparação para um fragmento, como descrito acima, o número total de símbolos de reparação para todos os fragmentos anteriores e, portanto, o índice de byte para o segmento de reparação, apenas depende de R, S, B(i-1) e B(i), e não depende de qualquer uma das estruturas anterior ou posterior dos fragmentos dentro do segmento de origem. Isto é vantajoso porque permite a um cliente calcular rapidamente a posição de início de um bloco de reparo dentro do segmento de reparação e também rapidamente calcular o número de símbolos de reparação dentro desse bloco de reparação, usando apenas informações locais sobre a estrutura do fragmento correspondente do segmento de origem do qual o bloco de reparação é gerado. Assim, se um cliente decide iniciar o download e reprodução de um fragmento no meio de um segmento de origem, ele pode também rapidamente gerar e acessar o bloco de reparação correspondente de dentro do segmento de reparação correspondente.

[000461]O número de símbolos de origem no bloco fonte correspondente ao fragmento é calculado como NSS(i) = ceiling((B(i)-B(i-1))/S). O último símbolo de origem é preenchido com zero bytes para efeitos de codificação e decodificação FEC se B(i)-B(i-1) não for um múltiplo de S, ou seja, o último símbolo de origem é preenchido com zero bytes para que seja de s bytes de tamanho para efeitos de codificação e decodificação FEC, mas estes zero bytes de preenchimento não são armazenados como parte do segmento de origem. Em tal modalidade, os ESIs para o símbolo de fonte são 0, 1,..., NSS(i)-1 e os ESIs dos símbolos de reparação são NSS(i),..., NSS(i)+RN(i)-1.

[000462]O URL para um segmento de reparação nesta modalidade pode ser gerado a partir do URL para o segmento de origem correspondente simplesmente por exemplo adicionando o sufixo “.repair” ao URL do segmento de origem.

[000463]As informações de índices de reparo e informações FEC para um segmento de reparação são implicitamente definidas pelas informações de indexação para o segmento de origem correspondentes, e a partir dos valores de R e S, conforme aqui descrito. Os deslocamentos de tempo e a estrutura do fragmento que inclui o segmento de reparação são determinadas pelos deslocamentos de tempo e estrutura do segmento de origem correspondente. O deslocamento/offset de bytes para o final dos símbolos de reparação no segmento de reparação correspondente ao fragmento i pode ser calculado como RB(i) = S*ceiling(R*B(i)/S). O número de bytes no segmento de reparação correspondente ao fragmento i é então RB(i)-RB(i-1), e, portanto, o número de símbolos de reparação correspondentes ao fragmento i é calculado como NRS(i) = (RB(i)-RB(i-1))/S. O número de símbolos de fonte correspondente ao fragmento pode ser calculado como NSS(i) = ceiling((B(i)-B(i-1))/S). Assim, na presente modalidade, as informações de indexação de reparação para um bloco de reparação dentro de um segmento de reparação e as informações correspondentes de FEC pode ser implicitamente derivadas a partir de R, S e das informações de indexação para o fragmento correspondente do segmento de origem correspondente.

[000464]Como exemplo, considere-se o exemplo apresentado na Figura 28, mostrando um fragmento 2 que começa no offset/deslocamento de byte B(1) = 6.410 e termina no offset/deslocamento de byte B(2) = 6.770. Neste exemplo, o tamanho do símbolo é S = 64 bytes, e as linhas verticais pontilhadas mostram os offsets de byte dentro do segmento de origem que correspondem aos múltiplos de S. O tamanho total do segmento de reparação como uma fração do tamanho de segmento da fonte é definida como R = 0.5 neste exemplo. O número de símbolos de fonte no bloco de origem para o fragmento 2 é calculado como NSS(2) = ceiling((6,770-6,410)/64) = ceil(5,625) = 6, e tais 6 símbolos de origem possuem ESIs 0,..., 5, respectivamente, em que o primeiro símbolo de fonte consiste dos primeiros 64 bytes do fragmento 2, que começa no índice de byte 6.410 dentro do segmento de origem, o segundo símbolo de fonte consiste dos próximos 64 bytes do fragmento 2, que começam no índice de byte 6.474 dentro do segmento de origem e assim por diante. O deslocamento de byte final do bloco de reparação correspondente ao fragmento 2 é calculado como RB(2) = 64*ceiling(0.5*6,770/64) = 64*ceiling(52.89...) = 64 * 53 = 3.392, e o deslocamento de byte inicial do bloco de reparação correspondente ao fragmento 2 é calculado como RB(1) = 64*ceiling(0.5*6,410/64) = 64*ceiling(50.07...) = 64 * 51 = 3.264, e assim, neste exemplo, existem dois símbolos de reparo no bloco de reparação correspondente ao fragmento 2 com ESIs 6 e 7, respectivamente, começando no deslocamento de byte 3.264 dentro do segmento de reparação e terminando no offset de byte 3.392.

[000465]Note-se que no exemplo mostrado na Figura 28, ainda que R = 0.5 e existem 6 símbolos fonte correspondentes ao fragmento 2, o número de símbolos de reparação não é 3, como se poderia esperar se fosse usado simplesmente o número de símbolos de fonte para calcular o número de símbolos de reparação, mas sim 2 de acordo com os métodos aqui descritos. Em oposição a simplesmente usar o número de símbolos de origem de um fragmento para determinar o número de símbolos de reparação, as modalidades descritas acima tornam possível calcular o posicionamento do bloco de reparo dentro do segmento de reparação unicamente a partir das informações de índice associados com o bloco de origem correspondente do segmento de origem correspondente. Além disso, a medida que o número, K, de símbolos de fonte em um bloco de origem cresce, o número de símbolos de reparação, KR, do bloco de reparação correspondente é estreitamente aproximado por K*R, como, em geral, KR é no máximo ceil(K*R) e KR é pelo menos floor((K-1)*R), onde floor(x) é o maior número inteiro que seja no máximo x.

[000466]Há muitas variações das modalidades acima para gerar uma estrutura de arquivo que pode ser vantajosamente utilizada por um cliente que emprega métodos de HTTP/FEC cooperativos, como notarão os técnicos na área. Como um exemplo de uma modalidade alternativa, um segmento original para uma representação pode ser particionado em n > 1 segmentos paralelos, onde para i = 1,..., N, uma fração especificada Fi do segmento original está contida no i° segmento paralelo, e onde a soma para i = 1,..., N de Fi é igual a 1. Em tal modalidade, pode haver um mapa de segmento mestre que é usado para derivar os mapas de segmentos para todos os segmentos paralelos, de forma similar àquela em que o mapa de segmento de reparação é derivado a partir do mapa de segmento de origem na modalidade descrita acima. Como exemplo, o mapa de segmento mestre pode indicar a estrutura do fragmento se todos os dados da mídia de origem não foram particionados em segmentos paralelos, mas em vez disso contidos em um segmento original, e o mapa de segmento para o i° segmento paralelo pode ser derivado do segundo mapa mestre, calculando que, se a quantidade de dados de mídia em um prefixo de primeiro de fragmentos do segmento original for L bytes, então o número total de bytes deste prefixo na total entre os primeiros i segmentos paralelos é ceil(L*Gi), onde Gi é a soma em j = 1,..., i de Fj. Como outro exemplo de uma modalidade alternativa, os segmentos podem consistir da combinação de dados de mídia de origem original para cada fragmento imediatamente seguido dos dados de reparação para esse fragmento, resultando em um segmento que contém uma mistura de dados de reparação gerados usando um código FEC proveniente dos dados de mídia de origem. Como outro exemplo de uma modalidade alternativa, um segmento que contém uma mistura de dados de mídia de origem e reparação pode ser particionado em múltiplos segmentos paralelos contendo uma mistura de dados de reparação e dados de mídia de origem.

[000467]Outras modalidades podem ser imaginadas pelos técnicos na área depois de ler esta divulgação. Em outras modalidades, combinações ou sub-combinações da invenção divulgada acima podem ser feitas vantajosamente. Os arranjos exemplares dos componentes são apresentados para fins de ilustração e deve ficar claro que combinações, adições, reorganizações e assim por diante são contempladas nas modalidades alternativas da presente invenção. Assim, apesar de a invenção ter sido descrita em modalidades exemplares, os técnicos na área irão reconhecer que várias modificações são possíveis.

[000468]Como exemplo, os processos aqui descritos podem ser implementados usando-se componentes de hardware, componentes de software e/ou quaisquer combinações de tais. Em alguns casos, os componentes de software podem ser providos por meio de mídia tangível, não transitórios para execução em hardware que são providos com os mídia, ou separados dos mídia. O relatório descritivo e os desenhos devem, portanto, ser considerados como ilustrativos e não restritivos. No entanto, ficará evidente que várias modificações e alterações podem ser efetuadas nos mesmos sem constituir um afastamento do mais amplo espírito e escopo da invenção tal como definidos nas reivindicações e que a invenção tenciona cobrir todas as modificações e equivalentes que se inserem no escopo das reivindicações que se seguem.

Claims

1. Método para gerar blocos de dados de mídia para serem transmitidos eletronicamente para dispositivos cliente mediante solicitação, o método caracterizado por compreender: - obter (103) dados que representam mídia de uma apresentação, em que a apresentação consiste de uma apresentação ao longo do tempo e possui uma taxa de reprodução definida e partes da apresentação podem ser definidas por faixas de tempo; - armazenar (110) os dados que representam mídia da apresentação como uma pluralidade de segmentos (510), em que cada segmento (510) compreende uma pluralidade de blocos (F, Blk) e dados de correspondência armazenados; - identificar, antes da transmissão de um subconjunto da pluralidade de blocos, correspondências entre uma pluralidade de faixas de tempo e uma pluralidade de posições dentro dos blocos dentro dos segmentos; - gerar, antes da transmissão do subconjunto da pluralidade de blocos, os dados de correspondência armazenados (S) representando pelo menos algumas das correspondências, tal que um dispositivo cliente possa determinar a partir dos dados de correspondência armazenados e de uma faixa de tempo desejada da apresentação a ser reproduzida, qual subconjunto solicitar da pluralidade de blocos.

2. Método, de acordo com a reivindicação 1, caracterizado peloos dados de correspondência armazenados serem armazenados como parte de um arquivo que também contém os dados de mídia.

3. Método, de acordo com a reivindicação 1, caracterizado pelos dados de correspondência armazenados constituírem um mapa formatado como metadados XML, em que a faixa de tempo é relativa ao início da apresentação ou relativa ao início de um bloco de mídia.

4. Método, de acordo com a reivindicação 1, caracterizado por gerar blocos de dados de mídia e os dados de correspondência armazenados serem realizados por um sistema de ingestão de mídia e armazenados em um servidor de propósito geral que responde ao menos às solicitações de arquivo.

5. Método, de acordo com a reivindicação 4, caracterizado pelas solicitações de arquivos serm solicitações HTTP.

6. Método, de acordo com a reivindicação 1, caracterizado pelos blocos de mídia possuírem duração variável e os dados de correspondência armazenados permitem aos dispositivos cliente determinar correspondências de localização de dados e faixas de tempo que podem variar dependendo das durações variáveis de blocos de mídia.

7. Método, de acordo com a reivindicação 1, caracterizado por um grupo de imagens, GOP, ser particionado em mais de um bloco de mídia.

8. Método para determinar solicitações para se realizar, em um dispositivo cliente que é capaz de apresentar uma apresentação de mídia durante um período de tempo de apresentação, o método caracterizado por compreender: - determinar, no dispositivo cliente, um período de tempo desejado da apresentação de mídia, em que o período de tempo desejado é menor que o total do período de tempo da apresentação; - obter, no dispositivo cliente, dados de correspondência armazenados (S) que mapeiam faixas de tempo da apresentação de mídia para faixas de dados dentro de segmentos que representam a mídia, em que cada segmento (510) compreende uma pluralidade de blocos (F, Blk) e dados de correspondência armazenados (S); - determinar (123), no dispositivo cliente, e a partir dos dados de correspondência armazenados e do período de tempo desejado, quais faixas de dados dos blocos solicitar do servidor de mídia; - realizar (124) as solicitações determinadas; e - apresentar (128) o período de tempo desejado da apresentação usando o dispositivo cliente.

9. Método, de acordo com a reivindicação 8, caracterizado pelos dados de correspondência armazenados serem armazenados como parte de um arquivo que também contêm os dados de mídia.

10. Método, de acordo com a reivindicação 8, caracterizado pelos dados de correspondência armazenados constituírem um mapa formatado como metadados XML, em que a faixa de tempo é relativa ao início da apresentação ou relativa ao início de bloco de mídia.

11. Método, de acordo com a reivindicação 8, caracterizado pelos blocos de dados de mídia e os dados de correspondência armazenados serem armazenados em um servidor de propósito geral que responde ao menos às solicitações de arquivo.

12. Método, de acordo com a reivindicação 11, caracterizado pelas solicitações de arquivo serem solicitações HTTP.

13. Aparelho para gerar blocos de dados de mídia para serem transmitidos eletronicamente para dispositivos cliente mediante solicitação, o aparelho caracterizado por compreender: - mecanismos para obter (103) dados que representam mídia de uma apresentação, em que a apresentação consiste de uma apresentação ao longo do tempo e possui uma taxa de reprodução definida e partes da apresentação podem ser definidas por faixas de tempo; - mecanismos para armazenar (110) os dados que representam mídia da apresentação como uma pluralidade de segmentos (510), em que cada segmento (510) compreende uma pluralidade de blocos (F, Blk) e dados de correspondência armazenados (S); - mecanismos para identificar, antes da transmissão de um subconjunto de blocos, correspondências entre uma pluralidade de faixas de tempo e uma pluralidade de posições dos blocos dentro dos segmentos; - mecanismos para gerar, antes da transmissão dos subconjuntos dos blocos, dados de correspondência armazenados (S) representando pelo menos algumas das correspondências, tal que um dispositivo cliente possa determinar a partir dos dados de correspondência armazenados e de uma faixa de tempo desejada da apresentação a ser reproduzida, qual subconjunto solicitar da pluralidade de blocos dentro dos segmentos.

14. Dispositivo cliente capaz de apresentar uma apresentação de mídia durante um período de tempo de apresentação, para determinar solicitações para se realizar, o dispositivo cliente caracterizado por compreender: - mecanismos para determinar, no dispositivo cliente, um período de tempo desejado da apresentação de mídia, em que o período de tempo desejado é menor que o total do período de tempo de apresentação; - mecanismos para obter, no dispositivo cliente, dados de correspondência armazenados (S) que mapeiam faixas de tempo da apresentação de mídia para faixas de dados de uma pluralidade de blocos de dados de mídia dentro de segmentos representando a mídia, em que cada segmentos (510) compreende uma pluralidade de blocos (F, Blk) e os dados de correspondência armazenados; - mecanismos para determinar (123), no dispositivo cliente, e a partir dos dados de correspondência armazenados e do período de tempo desejado, quais faixas de dados da pluralidade de blocos dentro dos segmentos solicitar; - mecanismos para realizar (124) as solicitações determinadas; e - mecanismos para apresentar (128) o período de tempo desejado da apresentação usando o dispositivo cliente.

15. Memória caracterizada por compreender instruções executáveis que, quando executadas, fazem com que pelo menos um computador execute um método conforme definido em qualquer uma das reivindicações 1 a 12.