BR112013025351B1

BR112013025351B1 - Método e dispositivo para recuperar dados de multimídia, método e dispositivo para enviar informações para dados de multimídia e memória legível por computador

Info

Publication number: BR112013025351B1
Application number: BR112013025351-7A
Authority: BR
Inventors: Thomas Stockhammer; Donald W. Gillies; Michael G. Luby; Fatih Ulupinar
Original assignee: Qualcomm Incorporated
Priority date: 2011-04-07
Filing date: 2012-04-05
Publication date: 2022-05-17
Also published as: SI2695355T1; PL2695355T3; JP2014515144A; PT2695355T; TWI465088B; HUE042019T2; CN103460667A; WO2012138895A1; KR20140004218A; EP2695355B1; CN103460667B; TW201251406A; JP6316781B2; KR101548444B1; DK2695355T3; EP2695355A1; ES2716274T3; US20120259946A1; US8849950B2; JP2016028474A

Abstract

STREAMING DE REDE DE DADOS DE VÍDEO UTILIZANDO SOLICITAÇÕES DE FAIXA DE BYTES. Em um exemplo, um dispositivo para receber informações para dados de multimídia inclui um ou mais processadores configurados para determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL), que especifica, na parte de percurso de arquivo do URL, de acordo com um gabarito, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

Description

[001] Este pedido reivindica o benefício do pedido provisório norte-americano No. 61/473,105, depositado a 7 de abril de 2011, que é por este incorporado em sua totalidade à guisa de referencia.

CAMPO DA INVENÇÃO

[002] Esta invenção refere-se ao armazenamento e transporte de dados de multimídia codificados.

DESCRIÇÃO DA TÉCNICA ANTERIOR

[003] As capacidades de vídeo digital podem ser incorporadas a uma ampla faixa de dispositivos, que inclui televisões digitais, sistemas de broadcast direto digitais, sistemas de broadcast sem fio, assistentes digitais pessoais (PDAs), computadores laptop ou de mesa, computadores tablet, leitoras de livros eletrônicos, câmeras digitais, dispositivos de gravação digitais, tocadores de meios digitais, dispositivos para jogos de vídeo, consoles para jogos de vídeo, telefones celulares ou de rádio-satélite, dispositivos de teleconferência de vídeo e semelhantes. Os dispositivos de vídeo digital implementam técnicas de compactação de vídeo, tais como as descritas nos padrões definidos pelo MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificação Avançada de Vídeo (AVC), e extensões de tais padrões para transmitir, receber e armazenar informações de vídeo digital de maneira mais eficaz.

[004] Depois que os dados de vídeo tiverem sido codificados, os dados de vídeo podem ser empacotados para transmissão ou armazenamento. Os dados de vídeo podem ser montados em um arquivo de vídeo que se conforma a qualquer um de diversos padrões, tais como o formato de arquivo de meios base da Organização Internacional para Padronização (ISSO) e extensões dele, tais como o formato de arquivo MP4 e o formato de arquivo de codificação avançada de vídeo (AVC). Tais dados de vídeo empacotados podem ser transportados de diversas maneiras, tais como transmissão através de uma rede de computadores com a utilização de fluxo contínuo em rede.

[005] Em meados dos anos 2000, o crescimento do tráfego e vídeo e áudio através da Internet por meio do Protocolo de Transporte em Tempo Real (RTP) começou a inundar a Internet com uma grande quantidade de tráfego de rede, e não havia controles de congestão para estes protocolos. Isto levou os administradores associados da tecnologia da informação (IT) a programar seus firewalls para bloquear pacotes RTP que continham fluxos de vídeo e áudio que estavam interrompendo os gateways nas corporações.

[006] Os firewalls ameaçavam a existência de serviços de fluxo contínuo de vídeo e áudio. Portanto, os provedores de serviços começaram a prover conteúdo através de circuitos virtuais TCP (mais especificamente, da porta HTTP do TCP). Eles fizeram isto para camuflar o seu tráfego de vídeo e áudio como tráfego HTTP. Os administradores de firewalls de IT não podiam bloquear facilmente vídeo e áudio através do HTTP/TCP e, assim, durante algum tempo, vídeo e áudio através do HTTP através do TCP floresceram.

[007] Inicialmente, um método de “download progressivo” foi utilizado para download da maioria dos vídeos. Neste mecanismo, uma única conexão e transferência HTTP é utilizada para efetuar download do arquivo de vídeo inteiro. O usuário vê o download ocorrer e, quando percebe que dados suficientes foram armazenados para suportar toda a experiência de ver os fluxos, ele aciona “EXECUTAR” e começa a exibir o vídeo. O executor pode iniciar a execução automaticamente uma vez efetuado o download de dados suficientes, proporcionando uma experiência de pseudo-fluxo contínuo. Este método apresentava problemas, contudo, quando o usuário queria ver vídeo imediatamente, especialmente em links de baixa capacidade. Outro problema era que, em um ambiente sem fio cambiante, o download adaptativo pode adotar subitamente um passo de lesma, provocando paradas no meio de um vídeo.

[008] Desde 2005, um trabalho vem sendo empreendido para implementar Fluxo Contínuo Adaptativo através do HTTP, que tenta resolver estes problemas. Exemplos de protocolos de fluxo contínuo adaptativo incluem o Fluxo Contínuo Suave da Microsoft (MSS), o Fluxo Contínuo ao Vivo da Apple (ALS), o Fluxo Contínuo Dinâmico HTTP Adobe (AHDS) e o Fluxo Contínuo Adaptativo Dinâmico através do HTTP (DASH) do Padrão HTTP. Em 2011, o serviço de fluxo contínuo de vídeo Netflix (baseado no MSS) consumiu 30% do transporte de retorno da Internet na América do Norte em momentos de pico, ao anoitecer, entregando pacotes de vídeo a residências de clientes.

[009] Os métodos de fluxo contínuo adaptativo organizam um vídeo muito à maneira de uma página da Web HTML. No DASH, por exemplo, uma “página de rede de vídeo” é definida como referindo todos os “fragmentos” (sub- arquivos, também referidos como sub-fragmentos) que constituem o vídeo. Um fragmento tem tipicamente 2 segundos de vídeo ou áudio em tempo real e começa tipicamente com um quadro MPEG-I (essencialmente uma imagem completa codificada por JPEG) em caso de vídeo. No H.264/AVC, tais quadros são referidos como quadros de Renovação Instantânea de Decodificador (IDR). No DASH, uma “página da Web de vídeo” é referida como “Descrição de Apresentação de Meios” (MPD). Uma MPD para um vídeo de 2 horas pode referir 3600 localizadores de recursos uniformes (URLs) de vídeo e 3600 URLs de áudio, cada um dos quais pode corresponder a 2 segundos de meios quando repetidos. Além disto, observe-se que 3600 URLs de vídeo podem ser providos para cada taxa de bits à qual o vídeo é codificado.

[0010] Um aperfeiçoamento do DASH é que o mesmo vídeo pode ser descrito a várias taxas de bits diferentes, e o executor pode comutar taxas de bits (a cada 2 segundos, por exemplo). Uma MPD descreve geralmente 3-8 renderizações diferentes do mesmo vídeo, referidas como representações. Quando a Internet está congestionada, ou quando o terminal está em um link de baixa capacidade, pode ser buscado um fragmento com baixa taxa de bits. Quando a Internet não está congestionada, e o terminal tem um link de alta capacidade, pode ser buscado um fragmento com alta taxa de dados. Tipicamente, é buscado um único fluxo de áudio e nenhuma comutação de taxa de bits ocorre com o áudio. Quando as condições de rede ou link se alteram, o executor pode adaptar-se buscando fragmentos de vídeo a taxas de bits mais altas ou mais baixas. O executor pode adaptar-se dinamicamente às condições de congestão cambiantes na Internet e transportar dados tanto de áudio quanto de vídeo através do HTTP. Note-se que, se 8 representações diferentes forem oferecidas, um total de 3600*8 = 28 800 fragmentos pode ser gerenciado no servidor de origem.

[0011] Depois que o HTTP 0.9 foi introduzido em 1993, ele teve um sucesso tão grande que a Internet foi logo inundada com solicitações de HTTP. Em seguida, em 1997, o HTTP 1.0 foi padronizado em RFC 2068, que incluía armazenamento em cache. Os navegadores começaram a armazenar objetos em cache, mas também os pesquisadores começaram a construir dispositivos de Cache Proxy HTTP transparentes de modo a tiraram vantagem dos novos recursos de armazenamento em cache no HTTP 1.0. Um dispositivo de cache proxy examina solicitações para OBTER HTTP e geralmente emite as solicitações sem alterá-las. Quando o cache proxy notifica uma resposta de HTTP com um dos cabeçalhos de “armazenamento em cache” ~5 HTTP (o que significa que o conteúdo tem um tempo de vida útil longo e pode ser armazenado em cache), tal como uma imagem jpeg ou uma cotação de ações válida por 20 minutos, o dispositivo de cache proxy pode armazenar a resposta armazenável em cache e reexecutá-la quando o mesmo usuário ou um usuário diferente solicitar o conteúdo posteriormente. Um administrador de redes pode reprogramar comutadores ou roteadores para rotear todo o tráfego HTTP através do seu cache proxy.

[0012] Além disso, o HTTP 1.1 (especificado em RFC 2616) proporciona solicitações de OBTENÇÃO parciais. As solicitações de OBTENÇÃO parciais incluem informações que especificam um URL-alvo, assim como um cabeçalho “Faixa:” seguido de valores que indicam a faixa de bytes desejada. Apesar do que o HTTP 1.1 proporciona, nem todos os navegadores da Web implementam a utilização de solicitações de OBTENÇÃO parciais. Além do mais, mesmo quando os navegadores da Web (ou outros aplicativos executados por um dispositivo cliente) implementam de fato solicitações de OBTENÇÃO parciais, dispositivos de rede intermediários, tais como servidores proxy, dispositivos de cache proxy ou outros dispositivos proxy, são frequentemente configurados para recuperar o arquivo completo, não apenas a parte solicitada pelo dispositivo cliente.

[0013] Os dispositivos proxy são comumente configurados para executar ações adicionais no tráfego de rede, tais como inspeção profunda nos pacotes para detecção de vírus ou outro tráfego de rede malicioso, armazenamento em cache (para responder a outras solicitações dos mesmos dados) ou outras funções que exigem recuperação de todo o arquivo. Portanto, tais dispositivos proxy tendem a se desfazer da solicitação de faixa e recuperar o arquivo inteiro no URL especificado e, assim, prover o arquivo recuperado ao dispositivo cliente solicitante. Por exemplo, determinados algoritmos de varredura de vírus exigem varredura de um arquivo inteiro, e neste caso é necessário efetuar o download do arquivo inteiro. Entretanto, para um arquivo multimídia relativamente grande (tal como um filme de duas horas), a recuperação do arquivo completo em vez da faixa de bytes solicitada pode impor retardos significativos à transmissão da faixa de bytes relativamente pequena para um dispositivo cliente solicitante.

SUMÁRIO DA INVENÇÃO

[0014] Em geral, esta invenção descreve técnicas relacionadas com a submissão de solicitações de faixas de bytes ao fluxo contínuo de dados de multimídia através de uma rede. Em vez de submeterem solicitações de faixas de bytes utilizando solicitações de OBTENÇÃO parciais, as técnicas desta invenção referem-se à especificação de faixas de bytes nos URLs de solicitações de OBTENÇÃO de HTTP. Desta maneira, não é necessário que a solicitação de faixa de bytes especifique um cabeçalho “Faixa:”, evitando-se assim o comportamento indesejado dos dispositivos de cache proxy intermediários. Ou seja, os dispositivos de cache proxy que são configurados para recuperar um arquivo completo, em resposta ao recebimento de uma solicitação de OBTENÇÃO parcial, devem recuperar apenas os dados parciais do URL solicitado. Quando o URL solicitado especifica uma faixa de bytes, os dados recuperados devem ser significativamente menores que o arquivo completo no URL base.

[0015] Em um exemplo, um método para recuperar dados de multimídia inclui determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[0016] Em outro exemplo, um dispositivo para recuperar informações para dados de multimídia inclui um ou mais processadores configurados para determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[0017] Em outro exemplo, um dispositivo para recuperar informações para dados de multimídia inclui meios para determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, meios para formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e meios para emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[0018] Em outro exemplo, um produto de programa de computador inclui um meio de armazenamento legível por computador que compreende instruções que, quando executadas, fazem com que o processador de um dispositivo para recuperar dados de multimídia determine a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, forme um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emita uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[0019] Em outro exemplo, um método para enviar informações para dados de vídeo inclui prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia e, em resposta à solicitação, transmitir dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[0020] Em outro exemplo, um dispositivo para enviar informações para dados de vídeo compreende um ou mais processadores configurados para prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia e, em resposta à solicitação, transmitir dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[0021] Em outro exemplo, um dispositivo para enviar informações para dados de vídeo inclui meios para prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, meios para receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia, e meios para transmitir, em resposta à solicitação, dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[0022] Em outro exemplo, um produto de programa de computador inclui um meio de armazenamento legível por computador que compreende instruções que fazem com que o processador de um dispositivo para prover dados de vídeo forneça um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receba uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia, e transmita, em resposta à solicitação, dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[0023] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição que se segue. Outros recursos, objetos e vantagens serão evidentes a partir da descrição e dos desenhos, e das reivindicações.

BREVE DESCRIÇÃO DAS FIGURAS

[0024] Figura 1 - é um diagrama de blocos que mostra um sistema exemplar que implementa técnicas para executar fluxo contínuo de dados de multimídia através de uma rede.

[0025] Figura 2 - é um diagrama de blocos que mostra um conjunto exemplar de dispositivos que fazem parte da rede da Figura 1.

[0026] Figura 3 - é um diagrama de blocos que mostra um sistema exemplar que inclui diversas redes de distribuição de conteúdo (CDNs).

[0027] Figura 4 - é um diagrama conceptual que mostra elementos de um conteúdo de multimídia exemplar.

[0028] Figura 5 - é um diagrama de blocos que mostra elementos de um arquivo de vídeo exemplar, que podem corresponder a um segmento de uma representação de conteúdo de multimídia.

[0029] Figura 6 - é um fluxograma que mostra um método exemplar para prover indicações de dados de gabarito de URL e para gerar solicitações de faixas de bytes utilizando os dados de gabarito de URL por um dispositivo cliente.

[0030] Figura 7 - é um fluxograma que mostra um método exemplar para gerar uma solicitação de OBTENÇÃO que especifica a faixa de bytes em um URL.

[0031] Figura 8 - é um fluxograma que mostra um método exemplar em que uma solicitação para OBTER HTTP é trocada entre um dispositivo cliente e um dispositivo servidor por meio de um dispositivo de rede intermediário.

[0032] Figura 9 - é um fluxograma que mostra um método exemplar para determinar uma CDN da qual recuperar dados de conteúdo de multimídia.

DESCRIÇÃO DETALHADA DA INVENÇÃO

[0033] Em geral, esta invenção descreve técnicas relacionadas com o fluxo contínuo de dados de multimídia, tais como dados de áudio e vídeo, através de uma rede. As técnicas desta invenção podem ser utilizadas em conjunto com o fluxo contínuo adaptativo dinâmico através do HTTP (DASH). Esta invenção descreve diversas técnicas que podem ser executadas em conjunto com o fluxo contínuo em rede, das quais qualquer uma ou todas podem ser implementadas sozinhas ou em qualquer combinação. Conforme descrito mais detalhadamente a seguir, diversos dispositivos que executam fluxo contínuo em rede podem ser configurados para implementar as técnicas desta invenção.

[0034] De acordo com o DASH e técnicas semelhantes para executar fluxo contínuo de dados através de uma rede, o conteúdo de multimídia (tal como um filme ou outro conteúdo de meios, que pode incluir também dados de áudio, dados de vídeo, superposições de texto ou outros dados) pode ser codificado de diversas maneiras e com diversas características. Um dispositivo de preparação de conteúdo pode formar várias representações do mesmo conteúdo de multimídia. Cada representação pode corresponder a um conjunto específico de características, tais como características de codificação e renderização, de modo a se proverem dados utilizáveis por diversos dispositivos de cliente com diversas capacidades de codificação e renderização. Além do mais, as representações que têm diversas taxas de bits podem proporcionar adaptação à largura de banda. Ou seja, um dispositivo cliente pode determinar uma quantidade de largura de banda que está atualmente disponível e selecionar uma representação com base na quantidade de largura de banda disponível, juntamente com as capacidades de codificação e renderização do dispositivo cliente.

[0035] Em alguns exemplos, um dispositivo de preparação de conteúdo pode indicar que um conjunto de representações tem um conjunto de características comuns. O dispositivo de preparação de conteúdo pode indicar então que as representações do conjunto formam um conjunto de adaptações, também referido como conjunto de adaptações, de modo que as representações do conjunto possam ser utilizadas para adaptação à largura de banda. Ou seja, as representações do conjunto podem diferir na taxa de bits, mas, caso contrário, compartilhar substancialmente as mesmas características. Desta maneira, um dispositivo cliente pode determinar diversos conjuntos de características comuns para conjuntos de adaptações de conteúdo de multimídia e selecionar um conjunto de adaptações com base nas capacidades de codificação e renderização do dispositivo cliente. Em seguida, o dispositivo cliente pode comutar adaptativamente entre representações no conjunto de adaptações selecionado com base na largura de banda disponível.

[0036] Os dados para as representações podem ser separados em arquivos individuais. Cada um dos arquivos pode ser endereçável por um localizador de recursos uniformes (URL) específico. Um dispositivo cliente pode submeter uma solicitação de OBTENÇÃO de um arquivo em um URL específico de modo a recuperar o arquivo. De acordo com as técnicas desta invenção, o dispositivo cliente pode modificar a solicitação de OBTENÇÃO incluindo uma indicação da faixa de bytes desejada dentro do percurso de URL propriamente dito, como, por exemplo, de acordo com um gabarito de URL fornecido por um dispositivo servidor correspondente. Note-se que, nesta invenção, o termo “percurso” pode indicar ou um percurso_abs HTTP [RFC2616] ou um percurso_rel HTTP [RFC2626][RFC2396]. A faixa de bytes indica ao dispositivo servidor que apenas a faixa de bytes indicada é desejada.

[0037] Desta maneira, as técnicas desta invenção incluem substituir solicitações de OBTENÇÃO parciais convencionais e, em vez disso, especificar a faixa de bytes desejada dentro do URL, como, por exemplo, no percurso de URL propriamente dito. Por exemplo, ao determinar que a faixa de bytes específica do arquivo de um arquivo endereçável pelo URL de uma representação é desejada, um dispositivo cliente pode construir uma solicitação de OBTENÇÃO para o URL especificando a faixa de bytes desejada dentro do percurso de URL, de acordo com as técnicas desta invenção. O criador de arquivos manifestos pode prover um gabarito para construir URLs desta maneira, assim como prover informações quanto a se o gabarito é necessário ou opcional. Além disto, dispositivos proxy ou outros dispositivos de rede intermediários podem ser configurados para converter solicitações de OBTENÇÃO parciais recebidas em URLs modificados, de acordo com as técnicas desta invenção. Desta maneira, os dispositivos proxy que são configurados para reconhecer solicitações de OBTENÇÃO parciais podem converter as solicitações de OBTENÇÃO parciais de acordo as técnicas desta invenção, de modo a se evitar ter dispositivos proxy upstream a modificarem a solicitação de OBTENÇÃO parcial em uma solicitação de OBTENÇÃO completa. Além disto, dispositivos de servidor podem ser configurados para responder não só a solicitações de OBTENÇÃO parciais, mas também a URLs modificados, e para especificar como construir URLs modificados que especifiquem as faixas de bytes de um arquivo, de acordo com as técnicas desta invenção.

[0038] Esta invenção provê também, em alguns exemplos, técnicas para sinalizar as características de conteúdo de multimídia relacionadas com as faixas de bytes especificadas explicitamente dentro de um URL. Esta invenção provê um atributo enumerado que faz parte do arquivo MPD, rotulado como “DeveUsar FaixaURL”. O valor para um campo que corresponde ao atributo indica se um dispositivo cliente pode (ou deve) especificar uma faixa de bytes desejada no URL propriamente dito. Esta invenção provê também um atributo enumerado que faz parte do arquivo MPD, rotulado como “FaixasDeBytesPermitidas”. Faixas de bytes solicitáveis podem ser especificadas dentro do arquivo MPD, dentro da caixa de índices de segmento (SIDX) de uma representação, ou podem ser não especificadas. O atributo FaixasDeBytesPermitidas fornece uma indicação de se um dispositivo cliente pode solicitar faixas de bytes especificadas pelo arquivo MPD, pela caixa SIDX ou por outras estruturas de dados de conteúdo de multimídia.

[0039] Esta invenção provê também um campo de GabaritoDeFaixaDeBytes que indica como a faixa de bytes será especificada. O campo de GabaritoDeFaixaDeBytes pode incluir um campo $URL$, um campo $IniciarBytes$ e um campo $EncerrarBytes$, que podem ser ordenados de acordo com um URL modificado formado apropriadamente, que especifica também uma faixa de bytes. O campo de GabaritoDeFaixaDeBytes pode especificar também caracteres adicionais, tais como outros símbolos ASCII. Utilizando o GabaritoDeFaixaDeBytes, o dispositivo cliente (ou dispositivo proxy) pode converter uma solicitação de OBTENÇÃO parcial (que inclui um campo “Faixa:”) em um URL modificado que especifica uma faixa de bytes sem a utilização de um campo “Faixa:” de acordo com as técnicas desta invenção.

[0040] Suponha-se, por exemplo, que um servidor da Web provê conteúdo de multimídia (o filme “TRON”, por exemplo) ou utilizando faixas de bytes ou servindo solicitações de faixa nas quais a faixa é embutida no URL. O servidor da Web é www.example.com, neste exemplo. O servidor da Web pode prover as indicações seguintes na MPD (ou arquivo manifesto) para o conteúdo de multimídia “TRON”. • GabaritoDeURL=http://www.example.com/TRON/segment.$Ban dwith$.$Index$:. • GabaritoDeFaixaDeBytes = “$Url$StartByte$EndByte$” • DeveUsarFaixaURL = 1 (= GabaritoDeFaixaDeByesOpcional) • FaixasDeBytesPermitidas = 0 (= FaixasApenasDeMPD)

[0041] Neste exemplo, o arquivo MPD indica que o gabarito de faixa de bytes é o URL, seguido de uma inserção e do byte inicial na faixa de bytes desejada, seguidos de outra inserção e do byte final na faixa de bytes desejada. DeveUsarFaixaURL indica que o gabarito de faixa de bytes é opcional, o que significa que o servidor responderá a solicitações de OBTENÇÃO parciais HTTP 1.1 assim como a URLs modificados que incluem solicitações de faixa, e o campo FaixasDeBytesPermitidas indica que é permitida apenas a especificação das faixas de bytes explicitamente indicadas na MPD.

[0042] Continuando com este exemplo, um URL e uma faixa de bytes convencionais podem ser expressos de acordo com o HTTP 1.1 como a solicitação de obtenção parcial seguinte: • OBTER http://www.example.com/TRON/segment.1000.27 HTTP/1.1 • Hospedeiro: www.example.com • Faixa: 435291-560829

[0043] Um dispositivo cliente (ou dispositivo proxy) de acordo com as técnicas desta invenção pode modificar a solicitação de OBTENÇÃO parcial acima de modo a formar o URL modificado seguinte: •OBTER http://www.example.com/TRON/segment.1000.27/435291/560829 HTTP/1.1 • Hospedeiro: www.example.com

[0044] Em geral, o dispositivo cliente pode gerar esta solicitação exemplar, em vez de gerar uma solicitação de OBTENÇÃO parcial convencional. Neste exemplo, o URL especifica explicitamente a faixa de bytes desejada (que é presumivelmente especificada na MPD para o conteúdo de multimídia, para fins de exemplificação).

[0045] Esta invenção também propõe a utilização de um cabeçalho de extensão para HTTP que indica que um URL inclui uma faixa de bytes. Isto pode permitir que um dispositivo proxy determine quando um URL inclui uma faixa de bytes, de modo que o dispositivo proxy possa pré- buscar dados para o conteúdo de multimídia para o dispositivo cliente que apresentou a solicitação.

[0046] Esta invenção provê também técnicas para selecionar uma rede de distribuição de conteúdo (CDN) ou grupo de servidores de conteúdo. Em alguns exemplos, o dispositivo cliente pode emitir uma solicitação de POST para um URL redirecionador, incluída no corpo da solicitação no URLBase. Um dispositivo servidor redirecionador pode receber o POST e emitir uma solicitação do arquivo que corresponde ao URLBase para uma CDN selecionada, como, por exemplo, com base nas características do dispositivo cliente solicitante, tais como o tipo de navegador de local do dispositivo cliente, a geografia da rede ou outros critérios de seleção discutidos a seguir. Em outros exemplos, os critérios de seleção podem ser especificados por uma pluralidade de CDNs, tais como hora do dia, retardo de ida e volta, contagem de saltos, localização e semelhantes. Um dispositivo cliente pode utilizar estes critérios para selecionar uma CDN. A seleção pode ser feita aleatoriamente com base nos critérios ou pela medição de características de rede que correspondem aos critérios de seleção e utilizar estes critérios para selecionar uma CDN de maneira determinística.

[0047] Em geral, as técnicas desta invenção podem ser utilizadas para superar um ou mais problemas relacionados com a execução de fluxo contínuo de dados de multimídia, especialmente com relação a partes solicitantes (fragmentos ou sub-fragmentos, por exemplo) de conteúdo de multimídia. Estes problemas incluem o fato de que nem todos os navegadores implementam solicitações de faixa de bytes. Uma vez que a faixa de bytes não é parte da especificação do URL-de fato, o cabeçalho “Faixa:” é um cabeçalho opcional enviado separadamente do URL-, as páginas da Web HTML são incapazes de referir faixas de bytes e, portanto, os navegadores não precisam implementar solicitações de faixa de bytes. Os navegadores que implementam de fato solicitações de faixa de bytes podem não permitir um plug in, tal como um plug-in de vídeo, para emitir uma solicitação de faixa de bytes. Este problema tem sido uma questão no desenho de plug-ins de navegador, tal como o plug-in do Adobe PDF Reader. Se os plug-ins para um navegador não puderem emitir solicitações de faixa de bytes, então um plug-in de DASH seria incapaz de buscar uma faixa de bytes de um arquivo de vídeo MPEG.

[0048] Além disso, embora seja possível distribuir arquivos de vídeo MPEG completos para CDNs cooperantes e recuperar arquivos MPEG parciais emitindo solicitações de faixa HTTP para CDNs cooperantes, o mesmo não é tão fácil de fazer com dispositivos de cache proxy. Não é necessário que os dispositivos de cache proxy implementem solicitações de faixa de bytes. Diversos dispositivos de cache proxy são tipicamente administrados por centenas de organizações diferentes, e há dúzias de implementações diferentes e, assim, não é possível assegurar que todos os dispositivos de cache proxy implementem solicitações de faixa de bytes. É procedimento legal no HTTP 1.1 responder a uma solicitação de faixa de bytes com o arquivo completo. Isto pode ser porque o navegador ignora a solicitação de faixa de bytes ou pode ser feita intencionalmente. Se um cache proxy implementar um varredor de vírus, o varredor pode converter uma solicitação de faixa de bytes em uma solicitação de arquivo completo, de modo a se recuperar tudo a fazer a varredura em busca de vírus, antes de se servir o conteúdo como resultado da faixa de bytes. Uma solicitação da Web típica hoje em dia pode passar por 3 ou mais dispositivos proxy (cache proxy de servidor de origem, proxy de transporte de retorno nacional, proxy de ISP local) e qualquer dispositivo proxy único (ou todos os dispositivos proxy) pode ser configurado para anular a solicitação de faixa de bytes.

[0049] Além do mais, relativamente poucos dispositivos de cache proxy são sofisticados o bastante para reconstruir um arquivo MPEG a partir de uma série de solicitações de faixa de bytes que ocorrem dentro de um período de tempo de duas hortas de um vídeo típico, por exemplo. A reconstrução de arquivos é difícil de implementar, quando muito poucos navegadores e apenas um subconjunto de plug-ins podem emitir solicitações de faixa de bytes. É bem mais provável que um cache (a) não armazene em cache solicitações de faixa de bytes de modo algum, ou (b) mantenha apenas a solicitação de faixa de bytes mais recente de um dado arquivo, ou (c) trate cada solicitação de faixa de bytes separada como um arquivo separado. Neste último caso, isto resultaria em até 72 000 fragmentos no cache proxy para um filme de duas horas com 10 fluxos com fragmentos de 2 segundos. O overhead de gerenciar muitos milhares de fragmentos para cada filme pode tornar-se ineficaz demais e incômodo para armazenamento em cache, neste caso.

[0050] As técnicas desta invenção incluem um mecanismo para executar fluxo contínuo de conteúdo de multimídia, como, por exemplo, conteúdo de multimídia de acordo com o protocolo DASH 3GPP, de modo a emitir solicitações de faixa de bytes dentro do URL que é buscado pelo navegador. Estas técnicas incluem também, em alguns exemplos, um gabarito genérico que define como as faixas de bytes podem ser mapeadas no URL, uma maneira de expressar se a utilização do gabarito é necessária ou meramente permitida (isto é, opcional), uma maneira de prover dados de um dispositivo cliente para servidores de origem e dispositivos proxy indicando que há uma faixa de bytes embutida em um URL e uma maneira de selecionar um gabarito com base no tipo de CDN para o URLBase e/ou URLGabaritoDeFaixaDeBytes. Qualquer uma ou todas estas técnicas podem ser utilizadas sozinhas ou em combinação.

[0051] Os arquivos de vídeo, tais como segmentos de representações de conteúdo de meios, podem conformar-se a dados de vídeo encapsulados de acordo com o formato de arquivo de meios base ISSO, o formato de arquivo da Codificação Escalonável de Vídeo (SVC), o formato de arquivo da Codificação Avançada de Vídeo (AVC), o formato de arquivo do Projeto de Parcerias de Terceira Geração (3GPP) e/ou o formato de arquivo da Codificação de Vídeo com Várias Vistas (MVC) ou outros formatos de arquivo de vídeo semelhantes.

[0052] O Formato de Arquivo de Meios Base ISSO é projetado para conter informações de meios temporizadas para uma apresentação em um formato extensível, flexível, que facilita o intercâmbio, o gerenciamento, a edição e a apresentação dos meios. O formato de Arquivo de Meios Base ISSO (ISSO/IEC 14496-12:2004) é especificado no MPEG-4 Parte 12, que define uma estrutura geral para arquivos de meios baseados no tempo. O formato de Arquivo de Meios Base ISSO é utilizado como a base para outros formatos de arquivo da família, tais como o suporte definido pelo formato de arquivo AVC (ISSO/IEC 14496-15) para compactação de vídeo H.264/MPEG-4 AVC, o formato de arquivo 3GPP, o formato de arquivo SVC e o formato de arquivo MVC. O formato de arquivo e o formato de arquivo MVC são extensões do formato de arquivo AVC. O formato de arquivo de meios base ISSO contém informações de temporização, estrutura e meios para sequências temporizadas de dados de meios, tais como apresentações de áudio-visuais. A estrutura de arquivo pode ser orientada para objetos. Um arquivo pode ser decomposto em objetos básicos de maneira muito simples e a estrutura dos objetos é implicada a partir do seu tipo.

[0053] Os arquivos que se conformam ao formato de arquivo de meios base ISSO (e extensões dele) podem ser formados como uma série de objetos, chamados de “caixas”. Os dados no formato de arquivo de meios base podem ser contidos em caixas, de modo que não seja necessário conter outros dados dentro do arquivo e não haja necessidade de dados fora das caixas dentro do arquivo. Isto inclui qualquer assinatura inicial exigida pelo formato de arquivo específico. Uma “caixa” pode ser um bloco de construção orientado para objetos definido por um identificador e um comprimento de tipo únicos. Tipicamente, uma apresentação é contida em um arquivo e a apresentação de meios é independente. O recipiente de filmes (caixa de filmes) pode conter os metadados dos meios, e os quadros de vídeo e áudio podem ser contidos no recipiente de dados de meios e podem estar em outros arquivos.

[0054] Uma representação (sequência de filme) pode ser contida em vários arquivos, às vezes referidos como segmentos. Informações de temporização e enquadramento (posição e tamanho) estão geralmente no arquivo de meios base ISSO e os arquivos auxiliares podem utilizar essencialmente qualquer formato. Esta apresentação pode ser ‘local’ ao sistema que contém a apresentação, ou pode ser provida por meio de uma rede ou outro mecanismo de entrega de fluxos.

[0055] Quando os meios são entregues através de um protocolo de fluxo contínuo, pode ser necessário transformar os meios a partir da maneira pela qual são representados no arquivo. Um exemplo disto é quando os meios são transmitidos através do Protocolo de Transporte em Tempo Real (RTP). No arquivo, por exemplo, cada quadro de vídeo é armazenado contiguamente como uma amostra de formato de arquivo. No RTP, as regras de empacotamento específicas do codec utilizado devem ser obedecidas de modo a se colocarem estes quadros em pacotes RTP. Um servidor de execução de fluxos contínuos pode ser configurado para calcular tal empacotamento no tempo de execução. Entretanto, há suporte para assistência aos servidores de execução de fluxos contínuos.

[0056] As técnicas desta invenção podem ser aplicadas a protocolos de execução de fluxos contínuos, tais como execução de fluxos contínuos HTTP, de acordo com a execução de fluxos contínuos dinâmica adaptativa através do HTTP (DASH). Na execução de fluxos contínuos HTTP, as operações utilizadas frequentemente incluem OBTENÇÃO e OBTENÇÃO parcial. A operação de OBTENÇÃO recupera um arquivo inteiro associado a um dado localizador de recursos uniformes (URL) ou outro identificador, como, por exemplo, um URI. A operação de OBTENÇÃO parcial recebe uma faixa de bytes como um parâmetro de entrada e recupera um número contínuo de bytes de um arquivo que corresponde à faixa de bytes recebida. Assim, fragmentos de filme podem ser providos para execução de fluxos contínuos HTTP, uma vez que uma operação de OBTENÇÃO parcial pode obter um ou mais fragmentos de filme individuais. Note-se que, em um fragmento de filme, pode haver vários fragmentos de trilha de trilhas diferentes. Na execução de fluxos contínuos HTTP, uma representação de meios pode ser uma coleção estruturada de dados que é acessível ao cliente. O cliente pode solicitar e efetuar download de informações de dados de meios de modo a apresentar um serviço de execução de fluxo contínuo ao usuário.

[0057] No exemplo de execução de fluxos contínuos de dados 3GPP com a utilização de fluxos contínuos HTTP, pode haver várias representações para dados de vídeo e/ou áudio de conteúdo de multimídia. A manifestação de tais representações pode ser definida em uma estrutura de dados da Descrição de Apresentação de Meios (MPD). Uma representação de meios pode corresponder a uma coleção estruturada de dados que é acessível a um dispositivo cliente de fluxo contínuo HTTP. O dispositivo cliente de fluxo contínuo HTTP pode solicitar e efetuar download de informações de dados de meios de modo a apresentar um serviço de fluxo contínuo ao usuário do dispositivo cliente. Uma representação de meios pode ser descrita na estrutura de dados MPD, que pode incluir atualizações da MPD.

[0058] Cada período pode conter uma ou mais representações para o mesmo conteúdo de meios. Uma representação pode ser uma de várias versões codificadas alternativas de dados de áudio ou vídeo. As representações podem diferir em diversas características, tais como tipos de codificação, como, por exemplo, por taxa de bits, resolução e/ou codec para dados de vídeo e taxa de bits, linguagem e/ou codec para dados de áudio. O termo representação pode ser utilizado para referir-se a uma seção de dados de áudio ou vídeo codificados que corresponde a um período específico do conteúdo de multimídia e codificada de maneira específica.

[0059] Representações de um período específico podem ser atribuídas a um grupo, que pode ser indicado por um atributo de grupo na MPD. Representações no mesmo grupo são geralmente consideradas alternativas umas com relação às outras. Por exemplo, cada representação de dados de vídeo para um período específico pode ser atribuída ao mesmo grupo, de modo que qualquer uma das representações possa ser selecionada para decodificação de modo a se exibirem dados de vídeo do conteúdo de multimídia para o período correspondente. O conteúdo de meios dentro de um período pode ser representado ou por uma representação do grupo 0, se presente, ou pela combinação de no máximo uma representação de cada grupo não zero, em alguns exemplos. Os dados de temporização para cada representação de um período podem ser expressos com relação ao tempo inicial do período.

[0060] Uma representação pode incluir um ou mais segmentos. Cada representação pode incluir um segmento de inicialização, cada segmento de uma representação pode ser auto-inicializador. Quando presente, o segmento de inicialização pode conter informações de inicialização para acessar a representação. Em geral, o segmento de inicialização não contém dados de meios. Um segmento pode ser referido de maneira única por um identificador, tal como um localizador de recursos uniformes (URL). A MPD pode prover os identificadores para cada segmento. Em alguns exemplos, a MPD pode prover também faixas de bytes sob a forma de um atributo de faixa, que pode corresponder aos dados para um segmento dentro de um arquivo acessível pelo URL ou URI.

[0061] Cada representação pode incluir também um ou mais componentes de meios, onde cada componente de meio pode corresponder a uma versão codificada de um tipo de meio individual, tal como áudio, vídeo e/ou texto temporizado (para legendas ocultas, por exemplo). Componentes de meios podem ser contínuos no tempo através de fronteiras de segmentos de meios consecutivos dentro de uma representação. Assim, uma representação pode corresponder a um arquivo individual ou a uma sequência de segmentos, cada um dos quais pode incluir as mesmas características de codificação e renderização.

[0062] As técnicas desta invenção, em alguns exemplos, podem proporcionar um ou mais benefícios. Por exemplo, estas técnicas podem permitir que nós proxy intermediários armazenem em cachê respostas de faixa de bytes apropriadamente. Estas técnicas podem fazer com que os nós proxy armazenem em cache de maneira apropriada faixas de bytes solicitadas mesmo quando os nós proxy não são configurados para armazenar em cache faixas de bytes solicitadas, mas são configurados para recuperar um arquivo inteiro. Para proporcionar tal armazenamento em cache apropriado, a faixa de bytes pode ser incorporada à parte de percurso de arquivo do URL. Pela incorporação da faixa de bytes ao percurso do arquivo, solicitações futuras exatamente da mesma faixa de bytes podem ser procuradas de maneira apropriada (utilizando-se o percurso de arquivo URL como uma chave) e produzir um “acerto” de cache. Isto pode acontecer porque a busca é tipicamente efetuada através do URL apenas (e não inclui o cabeçalho Faixa: como uma chave de busca).

[0063] Estas técnicas podem permitir também que o servidor de origem armazene as representações de vídeo (das quais há tipicamente de 3 a 8) utilizando um arquivo por representação, em vez de um arquivo por fragmento de 2 segundos, permitindo ao mesmo tempo que estes arquivos sejam armazenados em cache por nós intermediários. Isto pode reduzir o número de arquivos em um servidor de origem de 9600-28.000 para 3-8 e pode tornar o servidor de origem significativamente mais eficaz no armazenamento e recuperação de arquivos de vídeo.

[0064] Além disso, estas técnicas podem apresentar vantagens para servidores de armazenamento em cache (frequentemente, proxies de distribuição de conteúdo) que são configurados de acordo com métodos utilizados para incorporar faixas de bytes ao URL da solicitação para OBTER HTTP. Se estes servidores puderem reconhecer a solicitação, eles podem remontar os fragmentos de faixa de bytes e armazenar 3-8 arquivos para um vídeo de 2 horas, exatamente como o servidor de origem. Não é incomum que redes de distribuição de conteúdo implantem “aplicativos específicos de conteúdo” nestes proxies intermediários de modo a se praticar esta política de armazenamento em cache e recuperação personalizada. Portanto, este é um benefício muito prático e obtenível na Internet aberta.

[0065] Além do mais, estas técnicas podem proporcionar vantagens quando um vídeo é armazenado em cache por várias redes de distribuição de conteúdo diferentes. Devido a políticas diferentes ou capacidades diferentes de “aplicativos específicos de conteúdo”, pode ser necessário que o padrão exato da solicitação de faixa de bytes dentro do URL seja diferente para redes de distribuição de conteúdo diferentes. As técnicas descritas nesta invenção podem facilitar isto de maneira fácil e natural e podem permitir que o dispositivo cliente embuta solicitações de faixa de bytes de maneira diferente para redes de distribuição de conteúdo diferentes.

[0066] A Figura 1 é um diagrama de blocos que mostra um sistema 10 exemplar que implementa técnicas para executar fluxo contínuo de dados de meios através de uma rede. Neste exemplo, o sistema 10 inclui um dispositivo de preparação de conteúdo 20, o dispositivo servidor 60 e o dispositivo cliente 40. O dispositivo cliente 40 e o dispositivo servidor 60 são acoplados de maneira comunicativa pela rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo servidor 60 podem compreender o mesmo dispositivo. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 pode distribuir conteúdo preparado para uma pluralidade de dispositivos de servidor, inclusive o dispositivo servidor 60. Da mesma maneira, o dispositivo cliente 40 pode comunicar-se com uma pluralidade de dispositivos de servidor, inclusive o dispositivo servidor 60, em alguns exemplos.

[0067] Conforme descrito mais detalhadamente a seguir, qualquer um ou todos dos dispositivos de preparação de conteúdo 20, dispositivo servidor 60 e dispositivo cliente 40 podem ser configurados para executar técnicas correspondentes desta invenção. Por exemplo, o dispositivo servidor 60 e/ou o dispositivo de preparação de conteúdo 20 podem definir um gabarito genérico e enviar dados ao dispositivo cliente 40, como, por exemplo, em resposta a uma solicitação do dispositivo cliente 40, informando ao dispositivo cliente 40 como mapear faixas de bytes em um URL de modo a solicitar dados do dispositivo servidor 60, por exemplo. Da mesma maneira, o dispositivo cliente 40 pode submeter uma solicitação para recuperar dados de um URL, onde o URL da solicitação inclui uma faixa de bytes solicitada de acordo com o gabarito genérico. Além do mais, o dispositivo servidor 60 e/ou o dispositivo de preparação de conteúdo 20 podem prover informações ao dispositivo cliente 40 que indicam se a utilização do gabarito é necessária ou opcional.

[0068] Além disso, o dispositivo cliente 40 pode prover dados para dispositivos de rede intermediários (não mostrados na Figura 1) que informam aos dispositivos de rede intermediários que há uma faixa de bytes embutida em um URL. Os dispositivos de rede intermediários podem incluir dispositivos proxy, roteadores configurados para armazenar em cache ou inspecionar dados, ou semelhantes, e podem ser incluídos dentro da rede 74, conforme mostrado na Figura 2 e descrito mais detalhadamente a seguir. Além disto, o dispositivo cliente 40 pode utilizar um arquivo de manifesto de modo a determinar técnicas para selecionar uma rede de distribuição de conteúdo (CDN) da qual dados serão solicitados. O dispositivo servidor 60 representa um exemplo de dispositivo servidor que pode ser incluído em uma CDN. Outros dispositivos de servidor ou dispositivos de rede intermediários podem ser incluídos dentro de outras CDNs, conforme mostrado na Figura 4 e descrito mais detalhadamente a seguir. Em geral, a CDN é tipicamente escolhida e configurada pela entidade que cria o arquivo de manifesto (seja um arquivo de manifesto HTML ou uma MPD DASH). No caso da HTML, a escolha da CDN pode ser feita variando-se o nome de hospedeiro dentro dos URLs. No caso do DASH, uma CDN pode ser escolhida por uma combinação de nome de hospedeiro em URLs e a geração de padrões de URL CDN, de acordo com as técnicas desta invenção. De acordo com as técnicas desta invenção, cada CDN pode especificar um gabarito para gerar solicitações de faixa de bytes dentro de um URL propriamente dito que são específicas da CDN.

[0069] O dispositivo de preparação de conteúdo 20, no exemplo da Figura 1, compreende uma fonte de áudio 22 e uma fonte de vídeo 24. A fonte de áudio 22 pode compreender, por exemplo, um microfone que produz sinais elétricos que representam dados de vídeo captados a serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender um meio de armazenamento que armazena dados de áudio previamente gravados, um gerador de dados de áudio, tal como um sintetizador computadorizado ou qualquer outra fonte de dados de áudio. A fonte de vídeo 24 pode compreender uma câmera de vídeo que produz dados de vídeo a serem codificados pelo codificador de vídeo 28, um meio de armazenamento codificado com dados de vídeo previamente gravados, uma unidade de geração de dados de vídeo, tal como uma fonte de gráficos de computador ou qualquer outra fonte de dados de vídeo. O dispositivo de preparação de conteúdo 20 não é necessariamente comunicativamente acoplado ao dispositivo servidor 60 em todos os exemplos, mas pode armazenar conteúdo de multimídia em um meio separado que é lido pelo dispositivo servidor 60.

[0070] Dados de áudio e vídeo brutos podem compreender dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 26 e/ou pelo codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio de um participante falante enquanto o participante falante estiver falando, e a fonte de vídeo 24 pode obter simultaneamente dados de vídeo do participante falante. Em outros exemplos, a fonte de áudio 22 pode compreender um meio de armazenamento legível por computador que compreende dados de áudio armazenados, e a fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador que compreende dados de vídeo armazenados. Desta maneira, as técnicas descritas nesta invenção podem ser aplicadas a dados de áudio e vídeo ao vivo, de fluxo contínuo, em tempo real ou a dados de áudio e vídeo arquivados, pré-gravados.

[0071] Os quadros de áudio que correspondem a quadros de vídeo são geralmente quadros de áudio que contêm dados de áudio que foram captados pela fonte de áudio 22 contemporaneamente com os dados de vídeo captados pela fonte de vídeo 24 que são contidos dentro dos quadros de vídeo. Por exemplo, enquanto um participante falante produz geralmente dados de áudio pela fala, a fonte de áudio 22 capta os dados de áudio, e a fonte de vídeo 24 capta os dados de vídeo do participante falante ao mesmo tempo, isto é, enquanto a fonte de áudio 22 está captando os dados de áudio. Consequentemente, um quadro de áudio que corresponde a um quadro de vídeo corresponde geralmente a uma situação na qual os dados de áudio e os dados de vídeo foram captados ao mesmo tempo e para a qual um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram captados ao mesmo tempo.

[0072] O codificador de áudio 26 produz geralmente um fluxo de dados de áudio codificados, enquanto o codificador de vídeo 28 produz um fluxo de dados de vídeo codificados. Cada fluxo individual de dados (de áudio ou de vídeo) pode ser referido como fluxo elementar. Um fluxo elementar é um único componente codificado digitalmente (possivelmente compactado) de uma representação. Por exemplo, a parte de vídeo ou áudio codificada da representação pode ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar empacotado (PES) antes de ser encapsulado dentro de um arquivo de vídeo. Dentro da mesma representação, um ID de fluxo pode ser utilizado para distinguir os pacotes PES pertencentes a um fluxo elementar dos outros. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar empacotado (PES). Assim, os dados de vídeo codificados correspondem geralmente a fluxos de vídeo elementares. Da mesma maneira, os dados de áudio correspondem a um ou mais respectivos fluxos elementares.

[0073] À semelhança de muitos padrões de codificação de vídeo, o H.264/AVC define a sintaxe, a semântica e o processo de decodificação para fluxos de bits isentos de erros, qualquer um dos quais se conforma a um determinado perfil ou nível. O H.264/AVC não especifica o codificador, mas o codificador é encarregado de garantir que os fluxos de bits gerados se conformem ao padrão para um decodificador. No contexto de padrão de codificação de vídeo, um “perfil” corresponde a um subconjunto de algoritmos, recursos ou ferramentas e restrições que se aplicam a eles. Conforme definido pelo padrão H.264, por exemplo, um “perfil” é um subconjunto da sintaxe do fluxo de bits inteiro que é especificada pelo padrão H.264. Um “nível” corresponde às limitações do consumo de recursos do decodificador, tais como, por exemplo, a memória e a computação do decodificador, que estão relacionadas com a resolução das imagens, taxa de bits e taxa de processamento de macroblocos (MB). Um perfil pode ser sinalizado com um valor de idc_de_perfil (indicador de perfil), enquanto um nível pode ser sinalizado com um valor de idc_de_nível (indicador de nível).

[0074] O padrão H.264, por exemplo, reconhece que, dentro dos limites impostos pela sintaxe de um dado perfil, é ainda possível exigir uma grande variação no desempenho de codificadores e decodificadores dependendo dos valores assumidos pelos elementos de sintaxe no fluxo de bits, tais como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece também que, em muitas aplicações, não é nem prático nem econômico implementar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe dentro de um perfil específico. Por conseguinte, o padrão H.264 define “nível” como um conjunto especificado de restrições impostas aos valores dos elementos de sintaxe no fluxo de bits. Estas restrições podem ser limites simples sobre valores. Alternativamente, estas restrições podem assumir a forma de restrições às combinações aritméticas de valores (largura da imagem multiplicada pela altura da imagem multiplicada pelo número de imagens decodificadas por segundo, por exemplo). O padrão H.264 estabelece também que implementações individuais podem suportar um nível diferente para cada perfil suportado. Diversas representações de conteúdo de multimídia podem ser providas para acomodar diversos perfis e níveis de codificação dentro do H.264, assim como para acomodar outros padrões de codificação, tais como o padrão de Codificação de Vídeo de Alta Eficácia (HEVC) vindouro.

[0075] Um decodificador que se conforma a um perfil suporta geralmente todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, a codificação de imagens B não é suportada no perfil de linha base do H.264/AVC, mas é suportada em outros perfis do H.264/AVC. Um decodificador que se conforma a um nível específico deve ser capaz de decodificar qualquer fluxo de bits que não exija recursos além das limitações definidas no nível. As definições de perfis e níveis podem ser úteis para a capacidade de interpretação. Durante uma transmissão de vídeo, por exemplo, um par de definições de perfil e nível pode ser negociado e acordado para uma sessão de transmissão inteira. Mais especificamente, no H.264/AVC, um nível pode definir, por exemplo, limitações ao número de blocos que é necessário processar, o tamanho de buffer de imagens decodificadas (DPB), o tamanho de armazenador de imagens codificadas (CPB), a faixa de vetores de movimento verticais, o número máximo de vetores de movimento por dois MBs consecutivos e se um bloco B pode ter partições de sub-bloco menores que 8x8 pixels. Desta maneira, um decodificador pode determinar se o decodificador é capaz de decodificar apropriadamente o fluxo de bits.

[0076] Padrões de compactação de vídeo, tais como o ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 parte 10 e o padrão de Codificação de Vídeo de Alta Eficácia (HEVC) vindouro, utilizam predição temporal com compensação de movimento para reduzir a redundância temporal. O codificador, tal como o codificador de vídeo 28, pode utilizar uma predição com compensação de movimento de algumas imagens codificadas anteriormente (também aqui referidas como quadros) para predizer as imagens codificadas atuais de acordo com vetores de movimento. Há três tipos de imagem principais na codificação de vídeo típica. Eles são as imagens Intra-codificadas (“imagens I” ou “quadros I”), as imagens Preditas (“imagens P” ou “quadros P”) e as imagens preditas bidirecionais (“imagens B” ou “quadros B”). As imagens P podem utilizar a imagem de referência antes da imagem atual em ordem temporal. Em uma imagem B, cada bloco da imagem B pode ser predito a partir de uma ou duas imagens de referência. Estas imagens de referência podem ser localizadas antes ou depois da imagem atual em ordem temporal.

[0077] Os conjuntos de parâmetros contêm geralmente informações de cabeçalho de camada de sequência em conjuntos de parâmetros de sequência (SPS) e as informações de cabeçalho de camada de imagem infrequentemente cambiantes em conjuntos de parâmetros de imagem (PPS). Com os conjuntos de parâmetros, não é necessário repetir estas informações infrequentemente cambiantes para cada sequência ou imagem; consequentemente, a eficácia de codificação pode ser aperfeiçoada. Além disto, a utilização de conjuntos de parâmetros pode permitir a transmissão fora da banda de informações de cabeçalho, evitando a necessidade de transmissões redundantes de modo a se obter resiliência em termos de erros. Na transmissão fora da banda, unidades NAL de conjunto de parâmetros são transmitidas em um canal diferente do das outras unidades NAL.

[0078] No exemplo da Figura 1, a unidade de encapsulamento 30 do dispositivo de preparação de conteúdo 20 recebe fluxos elementares que compreendem dados de vídeo codificados do codificador de vídeo 28 e fluxos elementares que compreendem dados de áudio codificados do codificador de áudio 26. Em alguns exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem incluir, cada um, empacotadores para formar pacotes PES a partir de dados codificados. Em outros exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem, cada um, formar interface com respectivos empacotadores para formar pacotes PES a partir de dados codificados. Em ainda outros exemplos, a unidade de encapsulamento 30 pode incluir empacotadores para formar pacotes PES a partir de dados de áudio e vídeo codificados.

[0079] O codificador de vídeo 28 pode codificar dados de vídeo de conteúdo de multimídia de diversas maneiras, de modo a produzir representações diferentes do conteúdo de multimídia a diversas taxas de bits e com diversas características, tais como resoluções de pixel, taxas de quadros, conformidade a diversos padrões de codificação, conformidade a diversos perfis e/ou níveis de perfis para diversos padrões de codificação, representações que têm uma ou várias vistas (para repetição bidimensional ou tridimensional, por exemplo) ou outras características que tais. Uma representação, conforme utilizada nesta invenção, pode compreender uma combinação de dados de áudio e dados de vídeo, como, por exemplo, um ou mais fluxos elementares de áudio e um ou mais fluxos elementares de vídeo. Cada pacote PES pode incluir um id_de_fluxo que identifica o fluxo elementar ao qual o pacote PES pertence. A unidade de encapsulamento 30 é responsável pela montagem de fluxos elementares em arquivos de vídeo de diversas representações.

[0080] A unidade de encapsulamento 30 recebe pacotes PES para fluxos elementares de uma representação do codificador de áudio 26 e do codificador de vídeo 28 e forma unidades de camada de abstração de rede (NAL) correspondentes a partir dos pacotes PES. No exemplo do H.264/AVC (Codificação Avançada de Vídeo), segmentos de vídeo codificados são organizados em unidades NAL, que provêm uma representação de vídeo “amigável de rede” que endereça aplicativos tais como telefonia, armazenamento, broadcast ou fluxo contínuo de vídeo. As unidades NAL podem ser classificadas em unidades NAL de Camada de Codificação de Vídeo (VCL) e unidades NAL não VCL. As unidades VCL podem conter o mecanismo de compactação básico e podem incluir dados ao nível de bloco, macrobloco e/ou de fatia. Outras unidades NAL podem ser unidades NAL não VCL.

[0081] A unidade de encapsulamento 30 pode prover dados para uma ou mais representações de conteúdo de multimídia, juntamente com o arquivo de manifesto (a MPD, por exemplo), para a interface de saída 32. A interface de saída 32 pode compreender uma interface de rede ou uma interface para gravação em um meio de armazenamento, tal como uma interface com barramento serial universal (USB), um gravador ou queimador de CD ou DVD, uma interface com meios de armazenamento magnéticos ou flash ou outras interfaces para armazenar ou transmitir dados de meios. A unidade de encapsulamento 30 pode prover dados de cada uma das representações de conteúdo de multimídia para a interface de saída, que pode enviar os dados ao dispositivo servidor 60 por meio de transmissão em rede, transmissão direta ou meios de armazenamento. No exemplo da Figura 1, o dispositivo servidor 60 inclui um meio de armazenamento 62, que armazena diversos conteúdos multimídia 64, cada um deles incluindo um respectivo arquivo de manifesto 66 e uma ou mais representações 68A-68N (representações 68). De acordo com as técnicas desta invenção, partes do arquivo de manifesto 66 podem ser armazenados em locais separados, como, por exemplo, locais do meio de armazenamento 62 ou de outro meio de armazenamento, potencialmente de outro dispositivo da rede 74, tal como um dispositivo proxy.

[0082] Em alguns exemplos, as representações 68 podem ser separadas em conjuntos de adaptações. Ou seja, diversos subconjuntos das representações 68 podem incluir respectivos conjuntos comuns de características, tais como codec, perfil e nível, resolução, número de vistas, formato de arquivo para segmentos, informações sobre o tipo de texto que possam identificar a linguagem ou outras características do texto a ser exibido com a representação e/ou os dados de áudio a serem decodificados e apresentados, por exemplo, por alto-falantes, informações sobre o ângulo da câmera que podem descrever o ângulo da câmera ou a perspectiva de câmera no mundo real de uma cena para representações no conjunto de adaptações, informações de classificação que descrevem a adequação do conteúdo para audiências específicas ou semelhantes.

[0083] O arquivo de manifesto 66 pode incluir dados que indicam os subconjuntos das representações 68 que correspondem a conjuntos de adaptações específicos, assim como características comuns para os conjuntos de adaptações. O arquivo de manifesto 66 pode incluir também dados que representam características individuais, tais como taxas de bits, para representações individuais de conjuntos de adaptações. Desta maneira, um conjunto de adaptações pode proporcionar adaptação simplificada à largura de banda da rede. As representações em um conjunto de adaptações podem ser indicadas utilizando-se elementos- filhos de um elemento do conjunto de adaptações do arquivo de manifesto 66.

[0084] O dispositivo servidor 60 inclui uma unidade de processamento de solicitações 70 e uma interface de rede 72. Em alguns exemplos, o dispositivo servidor 60 pode incluir uma pluralidade de interfaces com rede, inclusive a interface de rede 72. Além disto, qualquer um ou todos os recursos do dispositivo servidor 60 podem ser implementados em outros dispositivos de uma rede de distribuição de conteúdo, tais como roteadores, pontes, dispositivos proxy, comutadores ou outros dispositivos. Em alguns exemplos, dispositivos intermediários de uma rede de distribuição de conteúdo podem armazenar em cache dados do conteúdo de multimídia 64 e incluem componentes que se conformam substancialmente aos do dispositivo servidor 60. Em geral, a interface de rede 72 é configurada para enviar e receber dados através da rede 74.

[0085] A unidade de processamento de solicitações 70 é configurada para receber solicitações de rede de dispositivos de cliente, tais como o dispositivo cliente 40, para dados do meio de armazenamento 72. Por exemplo, a unidade de processamento de solicitações 70 pode implementar a versão 1.1 do protocolo de transferência de hipertexto (HTTP), descrita em RFC 2616, “Protocolo de Transferência de Hipertexto - HTTP/1.1”, de R. Fielding et alii, Network Working Group, IETF, junho de 1999. Ou seja, a unidade de processamento de solicitações 70 pode ser configurada para receber solicitações de OBTENÇAO de HTTP e de OBTENÇÃO parciais e prover dados do conteúdo de multimídia 64 em resposta às solicitações. Em alguns exemplos, as faixas de bytes de um segmento podem ser especificadas utilizando-se solicitações de OBTENÇÃO parciais. Em outros exemplos, de acordo com as técnicas desta invenção, as faixas de bytes de um segmento podem ser especificadas como parte de um URL para o segmento, de acordo com um gabarito genérico, por exemplo.

[0086] A unidade de processamento de solicitações 70 pode ser também configurada para servir solicitações de CABEÇALHO HTTP de modo a prover dados de cabeçalho de um segmento de uma das representações 68. Seja como for, a unidade de processamento de solicitações 70 pode ser configurada para processar as solicitações de modo a prover dados para um dispositivo solicitante, tal como o dispositivo cliente 40. Além disto, a unidade de processamento de solicitações 70 pode ser configurada para gerar um gabarito para construir URLs que especificam faixas de bytes, prover informações que indicam se o gabarito é necessário ou opcional e prover informações que indicam se qualquer faixa de bytes é aceitável ou se apenas um conjunto específico de faixas de bytes é permitido. Quando apenas faixas de bytes específicas são permitidas, a unidade de processamento de solicitações 70 pode prover indicações das faixas de bytes permitidas.

[0087] Conforme mostrado no exemplo da Figura 1, o conteúdo de multimídia 64 inclui o arquivo de manifesto 66, que pode corresponder a uma descrição de apresentação de meios (MPD). O arquivo de manifesto 66 pode conter descrições de representações 68 alternativas diferentes (serviços de vídeo com qualidades diferentes, por exemplo) e a descrição pode incluir, por exemplo, informações de codec, um valor de perfil, um valor de nível, uma taxa de bits e outras características descritivas das representações 68. O dispositivo cliente 40 pode recuperar a MPD de uma apresentação de meios de modo a determinar como acessar segmentos das representações 68. No DASH convencional, há duas maneiras de especificar as faixas de bytes. A primeira maneira é pôr explicitamente faixas de bytes nas definições de fragmento individuais, armazenando as faixas de bytes na XML da MPD. A segunda maneira é buscar as informações sobre faixa de bytes na caixa SIDX no arquivo MPEG e utilizar essas informações sobre faixa de bytes SIDX para emitir solicitações de faixa de bytes para meios. As faixas de bytes discutidas acima podem ser especificadas utilizando-se ou uma ou a outra destas técnicas, ou outras técnicas, conforme será entendido pelos versados na técnica.

[0088] O aplicativo da Web 52 do dispositivo cliente 40 pode compreender um navegador da Web executado por uma unidade de processamento baseada em hardware do dispositivo cliente 40 ou um plug-in para tal navegador da Web. As referências ao aplicativo da Web 52 devem ser geralmente entendidas como incluindo ou um aplicativo da Web, tal como um navegador da Web, um dispositivo de vídeo independente ou um navegador da Web que incorpora um plugin de repetição ao navegador da Web. O aplicativo da Web 52 pode recuperar dados de configuração (não mostrados) do dispositivo cliente 40 de modo a determinar as capacidades de decodificação do decodificador de vídeo 48 e as capacidades de renderização da saída de vídeo 44 do dispositivo cliente 40.

[0089] Os dados de configuração podem incluir também qualquer uma ou todas de uma preferência de linguagem selecionada pelo usuário do dispositivo cliente 40, uma ou mais perspectivas de câmera que correspondem a preferências de profundidade estabelecidas pelo usuário do dispositivo cliente 40. O aplicativo da Web 52 pode compreender, por exemplo, um navegador da Web ou um cliente de meios configurado para submeter solicitações de OBTENÇÃO de HTTP e de OBTENÇÃO parciais. O aplicativo da Web 52 pode corresponder a instruções de software executadas por um ou mais processadores ou unidades de processamento (não mostradas) do dispositivo cliente 40. Em alguns exemplos, toda a ou partes da funcionalidade descrita com relação ao aplicativo da Web 52 podem ser implementadas em hardware ou em uma combinação de hardware, software e/ou firmware, onde o hardware necessário pode ser provido para executar instruções para software ou firmware.

[0090] O aplicativo da Web 52 pode comparar as capacidades de decodificação e renderização do dispositivo cliente 40 com as características das representações 68 indicadas pelas informações do arquivo de manifesto 66. O aplicativo da Web 52 pode recuperar inicialmente pelo menos uma parte do arquivo de manifesto 66 de modo a determinar as características das representações 68. Por exemplo, o aplicativo da Web 52 pode solicitar uma parte do arquivo de manifesto 66 que descreve as características de um ou mais conjuntos de adaptações. O aplicativo da Web 52 pode selecionar um subconjunto das representações 68 (um conjunto de adaptações, por exemplo) que tem características que podem ser satisfeitas pelas capacidades de codificação e renderização do dispositivo cliente 40. O aplicativo da Web 52 pode determinar então taxas de bits para representações no conjunto de adaptações, determinar a quantidade atualmente disponível de largura de banda de rede e recuperar segmentos (ou faixas de bytes) de uma das representações que têm uma taxa de bits que possa ser satisfeita pela largura de banda de rede.

[0091] Em geral, representações com taxas de bits mais elevadas podem apresentar repetição de vídeo de qualidade mais elevada, enquanto representações com taxas de bits mais baixas podem prover repetição de vídeo de qualidade suficiente quando a largura de banda de rede disponível diminui. Por conseguinte, quando a largura de banda de rede é relativamente alta, o aplicativo da Web 52 pode recuperar dados de representações com taxas de bits relativamente altas, ao passo que, quando a largura de banda de rede é baixa, o aplicativo da Web 52 pode recuperar dados de representações com taxas de bits relativamente baixas. Desta maneira, o dispositivo cliente 40 pode executar fluxo contínuo de dados de multimídia através da rede 74 se adaptando ao mesmo tempo à largura de banda de rede cambiante disponível da rede 74.

[0092] Conforme observado acima, em alguns exemplos o dispositivo cliente 40 pode prover informações de usuário, por exemplo, ao dispositivo servidor 60 ou a outros dispositivos de uma rede de distribuição de conteúdo. As informações de usuário podem assumir a forma de um cookie de navegador ou podem assumir outras formas. O aplicativo da Web 52, por exemplo, pode coletar um identificador de usuário, preferências de usuário e/ou informações demográficas de usuário e fornece tais informações de usuário ao dispositivo servidor 60. O aplicativo da Web 52 pode receber então um arquivo de manifesto associado a um conteúdo de meios de anúncio-alvo, a ser utilizado para inserir dados do conteúdo de meios de anúncio-alvo nos dados de meios do conteúdo de meios solicitado durante a repetição. Estes dados podem ser recebidos diretamente em consequência de uma solicitação do arquivo manifesto, ou de um sub-arquivo manifesto, ou estes dados podem ser recebidos por meio de um redirecionamento HTTP para um arquivo ou sub-arquivo alternativo (com base em um cookie de navegador fornecido, utilizado para armazenar dados demográficos de usuário e outras informações-alvo).

[0093] Às vezes, o usuário do dispositivo cliente 40 pode interagir com o aplicativo da Web 52 utilizando interfaces com usuário do dispositivo cliente 40, tais como um teclado, um mouse, uma caneta, uma interface com tela sensível ao toque, botões ou outras interfaces, para solicitar conteúdo de multimídia, tal como o conteúdo de multimídia 64. Em resposta a tais do usuário, o aplicativo da Web 52 pode selecionar uma das representações 68 com base, por exemplo, nas capacidades de codificação e renderização do dispositivo cliente 40. Para recuperar os dados da representação selecionada das representações 68, o aplicativo da Web 52 pode solicitar sequencialmente faixas de bytes específicas da representação selecionada das representações 68. Desta maneira, em vez de receber um arquivo completo através de uma solicitação, o aplicativo da Web 52 pode receber sequencialmente partes de um arquivo através de várias solicitações. De acordo com as técnicas desta invenção, o aplicativo da Web 52 pode formar solicitações que incluem um URL que especifica as faixas de bytes de acordo com um gabarito, por exemplo.

[0094] Em alguns exemplos, o dispositivo servidor 60 pode especificar um gabarito genérico para URLs de dispositivos de cliente, tais como o dispositivo cliente 40. O dispositivo cliente 40, por sua vez, pode utilizar o gabarito para construir URLs para solicitações para OBTER HTTP. No protocolo DASH, os URLs são formados ou listando- os explicitamente dentro de cada segmento, ou obtendo um GabaritodeURL, que é um URL que contém um ou mais padrões notoriamente conhecidos, tais como $$, $RepresentationID$, $Index$, $Bandwith$ ou $Time$ (descritos pela Tabela 9 do presente rascunho do DASH). Antes de marcar uma solicitação de URL, o dispositivo cliente 40 pode substituir cadeias de texto, tais como ‘$$’, o id de representação, o índice do segmento, etc., pelo GabaritodeURL de modo a gerar o URL final a ser buscado. Esta invenção define vários campos de XML adicionais que podem ser adicionados ao elemento Pré- DefinidoDeInfoDeSegmento de um arquivo DASH, como, por exemplo, em uma MPD para conteúdo de multimídia, tal como o arquivo de manifesto 66 para o conteúdo de multimídia 64.

[0095] Em alguns exemplos, o dispositivo servidor 60 pode prover dados que expressam a utilização do gabarito genérico, como, por exemplo, se o gabarito é necessário ou opcional, em um primeiro campo. Por exemplo, o dispositivo servidor 60 (ou um dispositivo proxy) pode prover ao dispositivo cliente 40 informações que indicam se ao dispositivo cliente é exigido ou simplesmente permitido utilizar o gabarito. O dispositivo servidor 60 pode fixar o valor de um elemento no arquivo de manifesto 66 de modo a indicar a utilização do gabarito. Por exemplo, um arquivo de MPD (que representa um exemplo do arquivo de manifesto 66) pode incluir um campo rotulado como “DeveUtilizarFaixaURL”, que pode assumir um de três valores: NãoIncorporarFaixaDeBytesAoUrl(0), FaixaDeBytesGabaritoOpcional(1) ou FaixaDerBytesGabaritoObrigatório(2). Em alguns exemplos, se o dispositivo servidor 60 fixar o valor em zero, os URLs buscados não devem conter faixas de bytes e o GabaritoDeFaixaDeBytes não deve ser utilizado. Em alguns exemplos, o dispositivo servidor 60 fixa o valor em um, em sua própria opção, e um executor DASH (o aplicativo da Web 52, por exemplo) pode emitir solicitações de faixa de bytes regulares, ou pode embutir as faixas de bytes dentro do URL propriamente dito. Em alguns exemplos, se o dispositivo servidor 60 fixar o valor em dois, o executor DASH deve emitir solicitações de faixa de bytes dentro do URL.

[0096] Outro campo provido por esta invenção é um atributo enumerado, “FaixasDeBytesPermitidas”, que pode assumir também um de três valores. O primeiro valor é FaixasApenasDaMPD(0). Quando o dispositivo servidor 60 especifica este valor, ao executor DASH (o aplicativo da Web 52, por exemplo) não é permitido utilizar faixas de bytes da SIDX (que podem ser incluídas dentro dos dados de uma respectiva representação das representações 68). Por conseguinte, pode-se restringir o executor DASH à utilização apenas de faixas de bytes da MPD DASH, como, por exemplo, o arquivo de manifesto 66. O segundo valor é FaixasDaSIDX(1). Quando o dispositivo servidor 60 especifica este valor, o executor DASH só pode utilizar faixas de bytes da SIDX (que, mais uma vez, podem ser incluídas como dados dentro de uma segmento de uma respectiva representação das representações 68) de modo a gerar solicitações de fragmentos ou segmentos. O terceiro valor, FaixasDeQualquerLugar(3), permite solicitações de faixa de bytes arbitrárias, inclusive a capacidade de utilizar a SIDX ou a MPD, e de combinar dois ou mais fragmentos em uma solicitação de fragmento, de solicitar dois ou mais segmentos ao mesmo tempo, ou outros híbridos de solicitações de um ou mais segmentos ou partes de segmentos, em uma solicitação de faixa de bytes.

[0097] Ainda outro campo provido por esta invenção é o campo GabaritoDeFaixaDeBytes. O dispositivo servidor 60 pode prover dados para este campo. De acordo com as técnicas desta invenção, o GabaritoDeFaixaDeBytes pode especificar um padrão de sequência que inclui os campos $Url$, $StartByte$ e $EndByte$. Além disto, o GabaritoDeFaixaDeBytes pode conter caracteres ASCCII adicionais a serem adicionados na emissão de solicitações de faixa de bytes baseadas em URL, ou pode incluir o símbolo “$$”, que representa um único sinal de dólar, como no elemento de GabaritoDeURL. O dispositivo cliente 40 pode substituir cada um dos três campos do GabaritoDeFaixaDeBytes por dados. Em particular, o dispositivo cliente 40 pode substituir um valor no campo $Url$ que corresponde ao valor do campo GabaritoDeURL. O dispositivo cliente 40 pode substituir também o URL resultante nos campos $StartByte$ e $EndByte$ pelos bytes iniciais e finais da faixa de bytes a ser solicitada. Desta maneira, o dispositivo cliente 40 pode produzir um URL que contém informações para uma solicitação de faixa de bytes. O dispositivo cliente 40 pode buscar dados deste URL construído por meio de uma solicitação de OBTENÇÃO que não contém nenhum campo “Faixa:” dentro dele. Ou seja, o dispositivo cliente 40 pode submeter a solicitação de OBTENÇÃO, que inclui um URL produzido, ao dispositivo servidor 60.

[0098] Deve ficar entendido pelos versados na técnica que é irrelevante se os padrões de sequência para um gabarito de faixa de bytes são armazenados em um atributo de GabaritoDeFaixaDeBytes, ou, em vez disso, se eles são armazenados no GabaritoDeURL. O armazenamento dos padrões de sequência para o gabarito nos atributos de GabaritoDeFaixaDeByte e de GabaritoDeURL é provido meramente para fins de exemplificação. Em geral, estes padrões de sequência podem ser armazenados em um ou no outro local ou em qualquer lugar no arquivo manifesto.

[0099] Um exemplo de solicitação que especifica dados para estes campos é apresentado a seguir. Neste exemplo, um servidor da Web (tal como o dispositivo servidor 60) serve conteúdo de multimídia (o filme “TRON”, por exemplo) ou utilizando faixas de bytes ou servindo solicitações de faixa de bytes no caso de a faixa ser embutida no URL. O servidor da Web pode ser, por exemplo, www.mp4player.com. São apresentados a seguir valores para este primeiro exemplo: GabaritoDeURL = http://www.mp4player.com/TRON/segment.$Bandwidth$Index$ GabaritoDeFaixaDeBytes = $Url$/$StartByte$/$EndByte$” DeveUtilizarFaixaURL = 1 (= GabaritoDeFaixaDeBytesOpcional). FaixasDeBytesPermitidas = 0 (= FaixasApenasDaMPD

[00100] Neste exemplo, o servidor da Web em www.mp4player.com indica que o gabarito de faixa de bytes é opcional para dispositivos de cliente, atribuindo um valor de ‘1’ ao elemento “DeveUtilizaURLDeFaixa”. Ou seja, o dispositivo cliente 40 pode especificar uma faixa de bytes como parte de um URL formado de acordo com o gabarito de URL e o gabarito de faixa de bytes, ou o dispositivo cliente 40 pode utilizar uma solicitação de OBTENÇÃO parcial convencional. Se o dispositivo cliente 40 optar por utilizar o gabarito, o dispositivo cliente submeteria uma solicitação do URL (http://www.mp4player.com/TRON/segment$Bandwidth$.$Index$) seguida de uma inserção ‘/’, um valor para $StartByte$, outra inserção ‘/’ e em seguida um valor para $EndByte$. Por conseguinte, o dispositivo cliente 40 pode construir um URL que tem duas partes: uma parte base que corresponde a uma representação específica e a um segmento dela, e uma parte de faixa de bytes que especifica um byte inicial e um byte final de uma faixa de bytes solicitada. A parte de faixa de bytes pode desempenhar essencialmente a função de um cabeçalho “Faixa:” em uma solicitação de OBTENÇÃO parcial, mas é especificada no percurso de URL propriamente dito, e não como um cabeçalho “Faixa:”. Para os versados na técnica, deve ser evidente que, uma vez que a faixa de bytes é especificada no percurso de URL, os resultados da solicitação de OBTENÇÃO podem ser potencialmente armazenados em cache por qualquer dispositivo intermediário, tal como um dispositivo proxy da Web transparente (ou explícito). Para os versados na técnica, dever ficar claro que solicitações armazenáveis em cache permitem que a repetição de vídeo seja escalonada para permitir que milhares ou até mesmo milhões de clientes solicitem o mesmo conteúdo ao mesmo tempo. Para os versados na técnica, deve ser evidente que, uma vez que a faixa de bytes é especificada de acordo com um gabarito, que pode ser diferente para redes de distribuição de conteúdo diferentes, é aliviado o encargo de obter redes de distribuição de conteúdo diferentes para adotar um e apenas um formato, para solicitações de faixa de bytes dentro de percurso de url.

[00101] Além do mais, neste exemplo o servidor da Web indica que apenas faixas de bytes especificadas na MPD podem ser especificadas, atribuindo um valor de ‘0’ ao elemento “FaixasDeBytesPermitidas”. Portanto, se o dispositivo cliente optar por especificar faixas de bytes utilizando o gabarito de faixa de bytes ou como uma solicitação de OBTENÇÃO parcial, ao dispositivo cliente só seria permitido especificar faixas de bytes especificadas no arquivo de MPD.

[00102] Supondo-se que um navegador da Web executado pelo dispositivo cliente (o aplicativo da Web 52 do dispositivo cliente 40, por exemplo) suporte solicitações de faixa de bytes e as suporte para plug-ins, um plug-in DASH pode emitir solicitações de Faixa de Byte utilizando o cabeçalho Faixa: do HTTP 1.1. Supondo-se um vídeo com taxa de bits de 1000 Kbps com ID de segmento=27, uma solicitação de OBTENÇÃO parcial que especifica uma faixa de bytes pode ser a seguinte: OBTER http://www.mp4player.com/TRON/segment.1000.27 HTTP/1.1 Hospedeiro: www.mp4player.com Faixa: 435291-560829

[00103] Se o navegador da Web não permitir que os seus plug-ins emitam solicitações de faixa de bytes, a solicitação, de acordo com o exemplo acima; pode ser a seguinte: OBTER http://www.mp4player.com/TRON/segment.1000.27/435291/560829 HTTP/1.1 Hospedeiro: www.mp4player.com

[00104] Desta maneira, as técnicas desta invenção podem permitir que um plug-in de navegador da Web (tal como o aplicativo da Web 52), executado por um dispositivo cliente (tal como o dispositivo cliente 40), emita solicitações de faixa de bytes mesmo quando o navegador envolvido não permitir que o cabeçalho “Faixa:” HTTP 1.0 oficial seja emitido no cabeçalho de solicitação. Da mesma maneira, o plug-in de navegador da Web pode utilizar estas técnicas para emitir a solicitação de faixa de bytes desta maneira mesmo se o navegador da Web não suportar solicitações de faixa de bytes, como, por exemplo, para processar situações nas quais outros dispositivos de rede (tais como dispositivos de rede intermediários, como, por exemplo, roteadores) não suportam ou processam apropriadamente solicitações de OBTENÇÃO parciais.

[00105] Em resposta às solicitações submetidas pelo aplicativo da Web 52 ao dispositivo servidor 60, a interface de rede 54 pode receber e prover dados de segmentos recebidos de uma representação selecionada ao aplicativo da Web 52. O aplicativo da Web 52 pode, por sua vez, prover os segmentos à unidade de desencapsulamento 50. A unidade de desencapsulamento 50 pode desencapsular os elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar os fluxos PES de modo a recuperar os dados codificados e enviar os dados codificados ou ao decodificador de áudio 46 ou ao decodificador de vídeo 48, dependendo de os dados codificados serem parte ou não de um fluxo de áudio ou de vídeo, conforme indicado por cabeçalhos de pacote PES do fluxo, por exemplo. O decodificador de áudio 46 decodifica os dados de áudio codificados e envia os dados de áudio decodificados à saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica os dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de vistas de um fluxo, à saída de vídeo 44.

[00106] O codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, o aplicativo da Web 52 e a unidade de desencapsulamento 50 podem, cada um, ser implementados como qualquer um de diversos circuitos de processamento adequados, conforme aplicável, tais como um ou mais microprocessadores, processadores de sinais digitais (DSPs), circuitos integrados específicos de aplicativo (ASICs), arranjos de portas programáveis no campo (FPGAs), circuitos lógicos discretos, software, hardware, firmware ou quaisquer combinações deles. Cada um dos codificador de vídeo 28 e decodificador de vídeo 48 pode ser incluído em ou mais codificadores ou decodificadores, ou um ou outro dos quais pode ser integrado como parte de um codificador/decodificador de vídeo combinado (CODEC). Da mesma maneira, cada um dos codificador de áudio 26 e decodificador de áudio 46 pode ser incluído em um ou mais codificadores ou decodificadores, ou um ou outro dos quais pode ser integrado como parte de um CODEC combinado. Um equipamento que inclui o codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, o aplicativo da Web 52 e/ou a unidade de desencapsulamento 50 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.

[00107] Desta maneira, o dispositivo cliente 40 representa um exemplo de dispositivo para recuperar informações para dados de multimídia que pode incluir um ou mais processadores configurados para determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[00108] Além do mais, o dispositivo servidor 60 representa um exemplo de dispositivo para enviar informações para dados de vídeo que pode incluir um ou mais processadores configurados para prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia e, em resposta à solicitação, transmitir dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[00109] A Figura 2 é um diagrama de blocos que mostra um conjunto exemplar de dispositivos que fazem parte da rede 74 da Figura 1. Neste exemplo, a rede 74 inclui dispositivos de roteamento 80A, 80B (dispositivos de roteamento 80) e um dispositivo de cache proxy 82. Os dispositivos de roteamento 80 e o dispositivo de cache proxy 82 se destinam a representar um pequeno número de dispositivos que podem formar parte da rede 74. Outros dispositivos de rede, tais como comutadores, hubs, gateways, firewalls, pontes e outros dispositivos que tais podem ser também incluídos dentro da rede 74. Além do mais, dispositivos de rede adicionais podem ser providos ao longo de um percurso de rede entre o dispositivo servidor 60 e o dispositivo cliente 40.

[00110] Em geral, os dispositivos de roteamento 80 implementam um ou mais protocolos de roteamento para trocar dados de rede através da rede 74. Em alguns exemplos, os dispositivos de roteamento 80 podem ser configurados para executar operações proxy ou de cache, tais como a funcionalidade atribuída ao dispositivo de cache proxy 82, conforme descrito a seguir. Portanto, em alguns exemplos, os dispositivos de roteamento 80 podem ser referidos como dispositivos proxy também. Em geral, os dispositivos de roteamento 80 executam protocolos de roteamento para descobrir rotas através da rede 74. Pela execução de tais protocolos de roteamento, o dispositivo de roteamento 80B pode descobrir uma rota de rede a partir dele mesmo até o dispositivo servidor 60 por meio do dispositivo de roteamento 80A.

[00111] Por conseguinte, o dispositivo de roteamento 80B pode receber comunicações de rede, tais como solicitações para OBTER HTTP encapsuladas pelo TCP-IP, do dispositivo cliente 40, destinadas ao dispositivo servidor 60. Em resposta a tais comunicações, o dispositivo de roteamento 80B pode determinar uma rota até o dispositivo servidor 60 e determinar também que a rota inclua o dispositivo de cache proxy 82. Por exemplo, o dispositivo de cache proxy 82 pode compreender um “próximo salto” ao longo da rota, ou um ou mais dispositivos de rede adicionais podem acoplar comunicativamente o dispositivo de roteamento 80B ao dispositivo de cache proxy 82. O dispositivo de cache proxy 82 pode direcionar a comunicação para o dispositivo de roteamento 80A, que pode emitir a comunicação para o dispositivo servidor 60.

[00112] O dispositivo de cache proxy 82 pode desempenhar funções de armazenamento em cache. O armazenamento em cache HTTP é importante para que a Internet funcione. Dispositivos proxy HTTP, tais como o dispositivo de cache proxy 82, podem implementar qualquer uma ou todas as versões do protocolo HTTP (HTTP 0.9, HTTP 1.0 e/ou HTTP 1.1, por exemplo). Além do mais, dispositivos de cache proxy, tais como o dispositivo de cache proxy 82, pode armazenar em cache conteúdo com base no “Localizador de Recursos Uniformes” (URL) que aparece em uma solicitação para OBTER HTTP. Este URL pode ser utilizado como a chave para procurar em seguida solicitações no cache. O dispositivo de cache proxy 82 pode ser configurado para armazenar em cache segmentos ou sub-segmentos de representações de conteúdo de multimídia, que podem corresponder a um URL, tal como um URL modificado, de acordo com as técnicas desta invenção.

[00113] Em alguns exemplos, redes de distribuição de conteúdo (CDNs) podem ser instaladas dentro da, ou comunicativamente acopladas à, rede 74. Exemplos de companhias que provêm CDNs incluem a Akamai, a Level 3 Communications e a Limelight. Os dispositivos de CDNs podem desempenhar funções semelhantes às do dispositivo de cache proxy 82. As CDNs podem colocar dispositivos que são muito semelhantes a dispositivos de cache proxy em ISPs e em portais de provedores de transporte de retorno nacionais. Por uma taxa, as CDNs podem distribuir conteúdo ou “pré- encher” os dispositivos de cache proxy com um conteúdo de cliente. O cliente pode em seguida referir o conteúdo e, através de uma técnica geralmente conhecida como “swizzling” DNS, um servidor de nomes inteligente pode direcionar uma solicitação de conteúdo para o cache da CDN local mais próxima, economizando um tempo de ida e volta valioso quando uma página da Web estiver sendo carregada. Alternativamente, o cliente pode pagar uma taxa diferente e o conteúdo pode ser apenas armazenado em cache, não tendo sido “pré-enchido” de antemão.

[00114] Conforme discutido acima, protocolos de rede de fluxo contínuo podem prover uma pluralidade de representações do mesmo conteúdo de multimídia. Assim, embora protocolos de fluxo contínuo adaptativo tais como DASH permitam adaptação, o benefício pode ser obtido a um custo elevado. O conteúdo de multimídia, que pode representar dezenas, centenas, milhares, milhões ou números maiores de bytes, pode ser codificado, por exemplo, a oito taxas de bits diferentes, e dividido em segmentos de dois segundos, mais um ou mais fluxos de áudio (estéreo ou Dolby 5.1, por exemplo), que podem ser também divididos em pedaços. Assim, um vídeo de duas horas pode resultar em 3600 ou mais fragmentos, vezes 10 fluxos, e os dados correspondentes podem consumir uma grande quantidade de armazenamento de diretório em um cache proxy ou em uma CDN.

[00115] Para evitar uma grande quantidade de armazenamento, o dispositivo servidor 60 pode ser configurado para receber arquivos individuais para cada um dos fluxos (dez arquivos no exemplo acima, por exemplo). O dispositivo cliente 40 pode recuperar segmentos ou sub- segmentos, utilizando solicitações de OBTENÇÃO de HTTP ou de OBTENÇÃO parciais, ou solicitações de faixa de bytes especificadas em URLs de solicitações de OBTENÇÃO, de acordo com as técnicas desta invenção. Em alguns exemplos, pilhas de protocolos HTTP podem ser utilizadas pelo dispositivo cliente 40 para emitir solicitações de faixa de bytes. Desta maneira, um filme típico de 36 000 fragmentos, por exemplo, pode ser desdobrado em dez arquivos: 8 de áudio e 2 de vídeo. De acordo com as técnicas desta invenção, o dispositivo cliente 40 pode recuperar faixas de bytes específicas utilizando solicitações para OBTER HTTP que incluem dados que representam um URL que especifica ele mesmo uma faixa de bytes.

[00116] Em alguns casos, quando um dispositivo proxy que não processa apropriadamente o cabeçalho “Faixa:”, mas recebe um cabeçalho “Faixa:” HTTP 1.1, o dispositivo proxy pode ignorar o cabeçalho e buscar e servir os arquivos inteiros, em vez das partes solicitadas dos arquivos. Isto pode ser desastroso para um arquivo de vídeo MPEG de 2 horas, que pode rodar até vários gigabytes de tamanho. Uma comutação de taxa no meio de tal fluxo pode fazer com que um cache proxy comece a buscar o arquivo inteiro para a nova taxa, do que resulta um retardo (até pelo menos metade dos dados chega ao cache, que é o tempo anterior em que o cache pode enviar de volta a resposta de conteúdo). Isto quebra a finalidade pretendida de solicitações de OBTENÇÃO parciais, que é a de recuperar partes pequenas de um arquivo em sequência de modo a se efetuar fluxo contínuo de rede. Para superar este problema, esta invenção provê técnicas para embutir de maneira transparente uma solicitação de faixa de bytes no URL, desviando-se assim de um cache proxy que converte as solicitações de cabeçalho “Faixa:” em solicitações de arquivo inteiro. Além do mais, esta invenção provê também técnicas para sinalizar que o servidor de origem deve procurar a solicitação de faixa de bytes.

[00117] Em particular, esta invenção provê técnicas para sinalizar faixas de bytes através de proxies intermediários que não suportam solicitações de faixa de bytes. Ou seja, o dispositivo cliente 40 pode submeter solicitações de faixa de bytes de modo que as solicitações de faixa de bytes sejam apropriadamente processadas por dispositivos de rede intermediários, tais como os dispositivos de roteamento 80 e os dispositivos de cache proxy 82. Conforme mencionado acima, um navegador da Web, tal como o aplicativo da Web 52 executado pelo dispositivo cliente 40, pode embutir uma solicitação de faixa em um URL de acordo com um gabarito de faixa de bytes não só nos casos em que o navegador da Web não implementa (ou não permite que plug-ins utilizem) solicitações de faixa de bytes de acordo com o HTTP 1.1, mas também para submeter uma solicitação de faixa quando dispositivos intermediários não suportarem ou processarem apropriadamente solicitações de OBTENÇÃO parciais. No decorrer do processo, uma vez que a faixa de bytes é embutida no URL, dispositivos proxy, tais como os dispositivos de roteamento 80 e/ou o dispositivo cache proxy 82, podem ser capazes de armazenar respostas de faixa de bytes parciais, mesmo quando os dispositivos proxy não entenderem solicitações de faixa de bytes. Por conseguinte, buscas futuras exatamente da mesma faixa de bytes devem fazer com que os dispositivos proxy busquem corretamente a faixa de bytes de dados do seu cache.

[00118] Esta invenção provê também um novo “cabeçalho de extensão” para o HTTP. Em geral, o HTTP permite cabeçalhos de extensão definidos pelo usuário em Solicitações para “OBTER” HTTP e em respostas de HTTP. Conforme definido na Seção 7.1 do documento RFC 2616, “campos de cabeçalho não reconhecidos DEVEM ser ignorados pelo destinatário e DEVEM ser emitidos por proxies transparentes”. Estes cabeçalhos de extensão são submetidos a parse como campos de cabeçalho de entidade que são reduzidos a campos de cabeçalho de extensão na solicitação de “OBTENÇÃO”. O nome de cabeçalho de extensão é qualquer cabeçalho HTTP não reconhecido (isto é, qualquer token alfabético). Embora o cabeçalho de extensão possa ser qualquer token alfabético ainda não definido pelo HTTP, tipicamente em cabeçalhos de mensagem SMTP, é garantido que o prefixo “X-“ nunca será utilizado em qualquer versão futura do SMTP, conforme definido no documento RFC822. O protocolo HTTP propriamente dito é baseado nos mecanismos de cabeçalho definidos no documento RFC822, e a convenção “X-“ é também utilizada por proxies HTTP para identificar cabeçalhos de extensão não HTTP, que são tipicamente emitidos—inalterados-para o servidor de origem e em seguida emitidos de volta—para o cliente-inalterados.

[00119] Esta invenção provê um novo cabeçalho de extensão chamado “X-Dash-FaixaDeBytes-URL”, que só aparece em solicitações para OBTER HTTP. O prefixo “X-“ é utilizado para evitar conflitos futuros com o HTTP. O prefixo “Dash” sinaliza que um cliente DASH está gerando o cabeçalho. Os versados na técnica verão que o nome exato deste cabeçalho não é importante; estas técnicas supõem que dispositivos de cliente e dispositivos de servidor são configurados de acordo com um nome comum para um cabeçalho de extensão.

[00120] Este cabeçalho fornece informações a nós intermediários e dispositivos proxy (que são configurados para interpretar o cabeçalho) de que uma faixa de bytes está incluída na solicitação para OBTER HTTP. Isto permite que um servidor de origem ou CDN armazene um arquivo MPEG como um único arquivo e, se ele(ela) entender este cabeçalho, ele(ela) pode utilizar o cabeçalho “X-Dash- FaixaDeBytes-URL” para determinar que há uma faixa de bytes embutida no URL.

[00121] Por conseguinte, o dispositivo cliente 40 pode prover o cabeçalho de extensão em uma solicitação de faixa, embutido dentro do URL de uma solicitação de OBTENÇÃO. Além do mais, quando dispositivos proxy, tais como os dispositivos de roteamento 80 e/ou o dispositivo cache proxy 82, são configurados para reconhecer o cabeçalho, os dispositivos proxy podem recuperar e prover apenas a faixa de bytes solicitada ao dispositivo cliente 40. Além do mais, o dispositivo cache proxy 82 e/ou os dispositivos de roteamento podem ser configurados para remontar um arquivo a partir de uma sequência de solicitações de faixa de bytes para o mesmo arquivo. Por outro lado, quando os dispositivos proxy, tais como os dispositivos de roteamento 80 e/ou o dispositivo cache proxy 82, não são configurados para interpretar o cabeçalho, os dispositivos proxy podem simplesmente fazer passar uma solicitação de OBTENÇÃO que inclui o cabeçalho na direção do dispositivo servidor 60.

[00122] O cabeçalho “X-Dash-FaixaDeBytes-URL” pode ter uma carga útil. Dois exemplos de carga útil são discutidos a seguir. Em um exemplo, a carga útil é vazia. A presença da faixa de bytes é sinalizada pela presença do cabeçalho. A faixa de bytes pode ser sempre anexada ao fim da solicitação para OBTER URL HTTP. O servidor de origem (o dispositivo servidor 60, por exemplo) ou dispositivo proxy (um dos dispositivos de roteamento 80 ou o dispositivo cache proxy 82, por exemplo) pode buscar então o URL do último caractere e deduz uma solicitação de faixa de bytes de comprimento máximo (utilizando uma busca pelos caracteres “0-9” e “-” e “,”, conforme definidos pela especificação de solicitação de faixa de bytes no documento RFC 2616).

[00123] O servidor de origem ou dispositivo proxy pode então, em alguns exemplos, remover a faixa de bytes do URL, abrir o arquivo (utilizando o URL com a faixa de bytes removida), buscar os bytes necessários e servir os bytes da faixa de volta para o dispositivo cliente 40. Este desenho é retro-compatível com proxies intermediários que não implementam o cabeçalho “X-Dash-FaixaDeBytes-URL”, e estes proxies intermediários armazenarão em cache corretamente a faixa de bytes e a servirão para clientes ou proxies de cliente em solicitações posteriores. Por exemplo, o dispositivo de cache proxy 82 pode ser configurado para reconhecer e processar o X-Dash- FaixaDeBytes-URL, ao passo que o dispositivo de roteamento 80B pode não ser configurado para processar o cabeçalho X- Dash-FaixaDeBytes-URL. No entanto, o dispositivo de roteamento 80B pode fazer passar solicitações que incluem este cabeçalho para o dispositivo de cache proxy 82, e o dispositivo de cache proxy 82 pode remover o cabeçalho de tais solicitações, recuperar a faixa de bytes solicitada, armazenar em cache os dados da faixa de bytes solicitada e prover a faixa de bytes solicitada ao dispositivo cliente 40 por meio do dispositivo de roteamento 80B. O dispositivo de cache proxy 82 pode armazenar em cache faixas de bytes subsequentes do mesmo arquivo e, em alguns exemplos, pode remontar um arquivo completo a partir de uma sequência de tais solicitações de faixa de bytes. Desta maneira, o dispositivo de cache proxy 82 pode evitar o carregamento do arquivo inteiro antes de prover apenas a faixa de bytes solicitada ao dispositivo cliente 40, o que de outro modo provocaria um retardo significativo na transmissão para o dispositivo cliente 40.

[00124] Entrementes, o servidor de origem, como, por exemplo, o dispositivo servidor 60, pode manter um fluxo de vídeo inteiro em um único arquivo MPEG, e pode servir solicitações de maneira mais eficaz e armazenar o vídeo MPEG de maneira mais eficaz no disco em um armazenamento não volátil (FLASH, por exemplo). Por exemplo, a solicitação seguinte pode ser utilizada para recuperar a faixa de bytes de um vídeo de acordo com as técnicas desta invenção: OBTER http://www.example.com/movies/1984TRON.1000.27123992- 240211 Hospedeiro: www.example.com X-Dash-FaixaDeBytes-URL

[00125] Em outro exemplo, a carga útil do cabeçalho X-Dash-FaixaDeBytes-URL contém a especificação de solicitação de faixa de bytes real do URL propriamente dito. Assim, ele funciona como um cabeçalho “Faixa:” definido pelo usuário, mas o comportamento é diferente. Um servidor de origem, tal como o dispositivo servidor 60, pode ser configurado para interpretar um cabeçalho “X-Dash- FaixaDeBytes-URL” com uma carga útil, e casar a carga útil deste cabeçalho com o URL de solicitação. Pela computação de uma correspondência entre padrões, o servidor de origem pode remover o especificador de faixa de bytes d URL e formar um novo URL, que é utilizado para buscar o arquivo MPEG completo do seu disco ou armazenamento não volátil. O servidor de origem pode utilizar então a especificação de faixa de bytes (utilizando novamente a mesma sintaxe especificada pelo documento RFC 2616) de modo a extrair os bytes necessários do arquivo MPEG. Por exemplo, a solicitação seguinte pode ser utilizada para recuperar a faixa de bytes de um vídeo de acordo com as técnicas desta invenção: OBTER http://www.example.com/movies/123992- 240211/1984TRON.1000.27 Hospedeiro: www.example.com X-Dash-FaixaDeBytes-URL: 123992-240211

[00126] O dispositivo servidor, proxy ou CDN (um do dispositivo servidor 60, dos dispositivos de roteamento 80 ou do dispositivo de cache proxy 82, por exemplo) pode regravar então esta solicitação e servir o conteúdo como se a solicitação tivesse sido feita como uma solicitação de OBTENÇÃO parcial convencional, da seguinte maneira, por exemplo: OBTER http://www.example.com/movies/1984TRON.1000.27 Hospedeiro: www.example.com Faixa: 123992-240211

[00127] Note-se que em sistemas de arquivos NFS e UNIX, a presença de dois ou mais caracteres “/” é tratada da mesma maneira que um caractere “/” único. Pode haver muitos benefícios nesta técnica. Um dispositivo de CDN ou proxy que é configurado para implementar este aperfeiçoamento no HTTP pode servir solicitações de faixa de bytes de um único arquivo MPEG, economizando espaço de armazenamento no disco. Um cache ou CDN proxy inteligente pode até mesmo construir um arquivo MPEG a partir de uma série destas solicitações de faixa, combinando todas estas solicitações de faixa em único arquivo armazenado em cache. Por exemplo, o dispositivo de cache proxy 82 pode ser configurado para construir um arquivo MPEG completo, ou outro arquivo de vídeo, a partir de uma pluralidade de solicitações de faixa de bytes sequenciais, do dispositivo cliente 40 ou de outros dispositivos de cliente, por exemplo.

[00128] Há outras implementações possíveis, como, por exemplo, no caso de um padrão ser especificado no cabeçalho “X-Dash-FaixaDeBytes-URL” ou em outro cabeçalho de extensão, para sinalizar a presença de uma faixa de bytes no URL, que pode ser removida pelo servidor de origem. Todas tais outras implementações são também contempladas para implementar as técnicas desta invenção.

[00129] Desta maneira, o dispositivo de cache proxy 82 representa um exemplo de dispositivo para enviar informações para dados de vídeo que pode incluir um ou mais processadores configurados para prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia e, em resposta à solicitação, transmitir dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[00130] A Figura 3 é um diagrama de blocos que mostra um sistema 90 exemplar que inclui diversas redes de distribuição de conteúdo 92A-92N (CDNs 92). Neste exemplo, o dispositivo de preparação de conteúdo 20 prepara conteúdo de multimídia em diversas representações e fornece uma ou mais representações a cada uma das CDNs 92. Em alguns exemplos, cada uma das CDNs 92 pode receber as mesma representações enquanto que, em outros exemplos, as CDNs 92 podem receber conjuntos diferentes de representações com relação às outras CDNs 92. Um dispositivo servidor semelhante ao dispositivo servidor 60, conforme discutido com relação às Figuras 1 e 2, pode ser provido em cada uma das CDNs. Alternativamente, um dispositivo proxy ou de cache pode ser provido em cada uma das CDNs 92. Além do mais, em alguns exemplos, algumas das CDNs 92 incluem dispositivos de servidor, enquanto outras das CDNs 92 incluem dispositivos proxy. O termo “CDN” é geralmente utilizado nesta invenção para referir-se a uma rede de entrega de conteúdo, a uma rede de distribuição de conteúdo, a um grupo de servidores de conteúdo ou a outra instalação semelhante. De acordo com as técnicas desta invenção, cada uma das CDNs 92 pode incluir um gabarito para URLs que especificam faixas de bytes que são específicas das respectivas CDNs.

[00131] Em alguns exemplos, determinadas CDNs 92 são ativas somente durante determinadas horas do dia, semana, mês, ano ou outro período de tempo. Por exemplo, a CDN 92A pode estar ativa durante as horas da manhã e da tarde, enquanto a CDN 92B pode estar ativa durante as horas da noite.

[00132] Esta invenção provê técnicas para selecionar uma CDN ou grupo de servidores de conteúdo, pelo dispositivo cliente 40, por exemplo, conforme descrito com relação à Figura 3. Supõe-se que um arquivo de MPD DASH inclui dados que indicam uma série de URLsBase, que são utilizados pare gerar solicitações de conteúdo DASH. Além do mais, supõe-se que cada URLBase se refere a uma CDN única, como, por exemplo, uma CDN única das CDNs 92. Por conseguinte, um executor DASH (executado pelo dispositivo cliente 40) pode ser configurado para selecionar uma CDN apropriada, selecionando um URLBase correspondente. Na Tabela 1 abaixo, é mostrada uma série de cinco critérios que pode ser utilizada para fazer a seleção. Há outros critérios que podem ser utilizados (adicional ou alternativamente), e estes cinco representam um conjunto muito mais amplo de critérios de seleção possíveis. Por conseguinte, critérios de seleção adicionais ou alternativos podem ser providos com relação aos mostrados na Tabela 1. TABELA 1-Critérios de Seleção de CDN Exemplares

[00133] Em um exemplo, o dispositivo cliente 40 pode selecionar uma das CDNs 92 especificando um URL de redirecionamento, que nomeia um serviço de redirecionamento. O dispositivo servidor de redirecionamento 94 representa um dispositivo, disponível no URL de redirecionamento, que executa o serviço de redirecionamento. Neste caso, o dispositivo cliente 40 pode enviar uma mensagem de POST ao URL de redirecionamento, fazendo com que a mensagem de POST seja direcionada para o dispositivo servidor de redirecionamento 94. No corpo da mensagem, o dispositivo cliente 40 pode especificar um URLBase Solitário. O dispositivo servidor de redirecionamento 94 pode inspecionar então o URLBase e tomar uma decisão sobre qual das CDNs 92 utilizar e enviar de volta um novo URLBase no corpo de uma resposta de HTTP ao dispositivo cliente 40. A decisão pode ser baseada em conceitos tais como a localização do dispositivo cliente POSTador (um protocolo de localização pode mapear o endereço IP do cliente em uma localização), o tipo de navegador (indicado na solicitação de POST), a geografia da rede e/ou qualquer um dos critérios de seleção enumerados na Tabela 1, ou critérios semelhantes. Note-se que, em vez de utilizar um método de POST, o dispositivo cliente 40 pode utilizar alternativamente um método de OBTENÇÃO (enviando conteúdo no corpo do método de OBTENÇÃO), e o servidor de redirecionamento pode redirecionar o dispositivo cliente 40 para a primeira peça de conteúdo na CDN diretamente, utilizando uma resposta 301 (Conteúdo Movido) ou 307 (Redirecionamento Temporário) HTTP.

[00134] Em alguns casos, o dispositivo cliente pode não ser configurado para atuar nas informações de seleção de CDN na MPD, de modo que ele pode postar não só o URLBase para o servidor de redirecionamento, mas também os critérios de seleção para o servidor e, em terceiro lugar, ele pode postar todas ou algumas das suas informações locais (tais como informações de geolocalização, contagens de saltos, hora local do dia, etc.) para o dispositivo servidor de redirecionamento 94. Neste caso, o servidor de redirecionamento 94 pode executar o processo de tomada de decisões inteiro e enviar de volta o URLBase que deve ser utilizado pelo dispositivo cliente 40.

[00135] Além disso, o dispositivo servidor de redirecionamento 94 pode ser configurado para analisar informações que podem depender do conteúdo de multimídia específico que o dispositivo cliente 40 pede para ver. Alguns títulos de vídeo não estão necessariamente disponíveis em cada uma das CDNs 92. Por exemplo, determinado conteúdo pode não estar disponível em uma CDN em um determinado país devido a restrições de exportação ou de direitos autorais. Tais decisões de seleção de conteúdo podem ser tomadas através da implementação deste exemplo. No contexto do DASH, um atributo opcional chamado “BaseURL@redirectionUrl” pode conter o URL utilizado em tais solicitações de POST por meio do HTTP.

[00136] Em outros exemplos, um novo atributo DASH, chamado BaseURL@selectionAttribute, por exemplo, pode ser utilizado para indicar um ou mais atributos de seleção. Ou seja, o dispositivo cliente 40 pode receber dados para este atributo de um servidor ou outro dispositivo, como, por exemplo, um dispositivo de uma das CDNs 92 ou outro dispositivo. O conteúdo deste atributo é uma lista de zeros ou mais números, que podem especificar um ou mais critérios de seleção. Além disto, determinados números podem ter uma série de argumentos, com um argumento para cada URLBase. Nestes exemplos, não é necessário haver um URL de redirecionamento. Além do mais, não é necessário especificar um Atributo de seleção. Ou seja, por pré- definição, é solicitado o comportamento do Atributo de seleção. Neste caso, um executor DASH, executado no dispositivo cliente 40, pode comportar-se como se o critério de seleção fosse “Aleatório Ponderado” com pesos iguais em todos os URLsBase possíveis. O executor DASH pode fazer uma seleção aleatória e uniforme entre todos os URLsBase e em seguida fazer todas as solicitações futuras utilizando o URLBase selecionado.

[00137] Em ainda outro exemplo, apenas um critério de seleção aparece no AtributoDeSeleção. Neste exemplo, o executor DASH determina uma CDN apropriada das CDNs 92 utilizando critérios de seleção simples, como, por exemplo, seleção aleatória para equilibrar a carga dos servidores, hora do dia, retardo de ida e volta, contagem mínima de saltos, e/ou utilizando critérios de localização. O cliente DASH faz então todas as solicitações futuras utilizando o URLBase selecionado. Por exemplo, um valor de <AtributoDeSeleção=“1(0,2, 0,2, 0,3, 0,3)”> pode fazer com que o mecanismo de balanceamento de carga, executado pelo dispositivo cliente, selecione aleatoriamente entre todos os URLsBase possíveis. Entretanto, há 20% de possibilidade de escolher os dois primeiros URLsBase e 30% de possibilidade de escolher os dois últimos URLsBase. Uma vez que um URLBase é escolhido, o cliente DASH continuaria a reutilizar o URLBase escolhido em solicitações futuras.

[00138] Em ainda outro exemplo, mais de um AtributoDeSeleção pode ser especificado. Por exemplo, pode haver um valor tal como <AtributoDeSeleção=“3, 4, 2 (0-359, 359-1439, 0-1429, 1080-1439), 1(0,2, 0,2, 0,2, 0,4)”>. Neste exemplo, a presença de AtributosDeSeleção adicionais indica que o executor DASH deve utilizar o critério 3 primeiro, em seguida o critério 4, em seguida o critério 2, em seguida romper laços com o critério 1 de acordo com os pesos dados, isto é, 0,2, 0,2, 0,2 e 0,4. Note-se que, se alguns URLsBase já foram eliminados, os pesos restantes podem ser escalonados de maneira ascendente de modo que a sua soma seja 1,0.

[00139] Para ilustrar este exemplo, suponha-se que haja 4 URLsBase potenciais A, B, C e D, onde os URLsBase correspondem a respectivas CDNs. Por exemplo, A pode corresponder à CDN 92A, B pode corresponder à CDN 92B, C pode corresponder à CDN 92C e D pode corresponder à CDN 92D. Em primeiro lugar, o retardo de ida e volta (RTD) pode ser calculado para cada um de A, B, C e D, utilizando-se mensagens ping. Isto pode indicar que os RTDs são os seguintes: A-20 mseg; B-20 mseg; C-33 mseg; D-40 mseg. Em seguida, a lista de escolha, em preferência decrescente, é: A, B, C e D, onde A e B ligados primeiro. Por conseguinte, o total de saltos para cada um de A, B, C e D pode ser medido utilizando-se, por exemplo, mensagens ping do protocolo de mensagens de controle da Internet (ICMP). Ou seja, o dispositivo cliente 40 pode submeter mensagens ping ICMP a respectivas CDNs das CDNs 92 de modo a calcular o total de saltos para cada uma. Para fins de exemplificação, suponha-se que sejam determinados para os totais de saltos os valores seguintes: A-5 saltos; B-3 saltos; C-12 saltos; D-20 saltos. Em seguida, a lista de escolha em preferência decrescente é B, A, C, D, porque é determinado que B tem menos saltos que A, o que torna B mais desejável.

[00140] Continuando com este exemplo, pode-se determinar que a hora do dia é 15 h, por exemplo. Os valores de hora do dia sinalizados para os URLsBase pode ser os seguintes: A-de 6 da manhã até meia-noite; B-de meia-noite até as 6 da manhã; C-de 6 da manhã até meia- noite; D-o dia inteiro. O dispositivo cliente pode eliminar então A e B, supondo que a hora do dia atual é 15 h, uma vez que 15 h fica fora das faixas de horas do dia para A e B, neste exemplo. Assim, a escolha final pode recair em C ou D (a CDN 92C ou 92D, por exemplo). Pode ser feita a escolha lexicográfica mínima, que corresponde a C, uma vez que 33 mseg < 40 mseg.

[00141] Em ainda outro exemplo, pode haver um pequeno número de CDNs, mas um grande número de restrições de hora do dia, pesos de balanceamento de carga ou restrições semelhantes às CDNs. Neste exemplo, se houver N URLsBase, o AtributoDeSeleção pode conter algumas restrições, mas cada restrição pode ter mais de N argumentos. O (N+1)o argumento pode referir-se ao URL No.1, o (N+2)o pode referir-se ao URL No. 2 e assim por diante. Desta maneira, os URLsBase podem repetir-se quando houver mais de N argumentos. Este exemplo pode economizar espaço de armazenamento ao tornar desnecessário repetir URLsBase. Neste caso, o número de argumentos para cada restrição deve conferir. Isto é especialmente útil para restrições tais como a hora do dia.

[00142] Para ilustrar este exemplo, com 4 CDNs A, B, C, D, pode haver restrições de balanceamento de carga diferentes dependendo da hora do dia. Durante a manhã, as CDNs 92A e 92B, podem receber 80% da carga, equilibrada de maneira uniforme, mas, durante a noite, as CDNs 92C e 92D recebem 70% da carga, equilibrada de maneira uniforme. Esta restrição pode ser descrita da maneira seguinte: <AtributoDeSeleção=“2(0-719, 0-719, 0-719, 0-719, 720-1439, 720-1439, 720-1440, 720-1439)1(0,4, 0,4, 0,1, 0,1, 0,1, 0,2, 0,35, 0,35)”>.

[00143] A Figura 4 é um diagrama conceptual que mostra elementos de um conteúdo de multimídia 100 exemplar. O conteúdo de multimídia 100 pode corresponder ao conteúdo de multimídia 64 (Figura 1) ou a outro conteúdo de multimídia armazenado na memória 62. No exemplo da Figura 4, o conteúdo de multimídia 100 inclui uma descrição de apresentação de meios (MPD) 102 e uma pluralidade de representações 110-120. A representação 110 inclui dados de cabeçalho opcionais 112 e segmentos 114A-114N (segmentos 114), enquanto a representação 120 inclui dados de cabeçalho opcionais 122 e segmentos 124A-124N (segmentos 124). A letra N é utilizada para designar o último fragmento de filme em cada uma das representações 110, 120 por conveniência. Em alguns exemplos, pode haver números diferentes de fragmentos de filme entre as representações 110, 120.

[00144] A MPD 102 pode compreender uma estrutura de dados separada das representações 110-120. A MPD 102 pode corresponder ao arquivo de manifesto 66 da Figura 1. Da mesma maneira, as representações 110-120 podem corresponder às representações 68 da Figura 1. Em geral, a MPD 102 pode incluir dados que descrevem geralmente características das representações 110-120, tais como as características de codificação e renderização, conjuntos de adaptações, o perfil ao qual a MPD 102 corresponde, informações sobre o tipo de texto, informações sobre o ângulo de câmera, informações de classificação, informações sobre modo de truque (informações que indicam representações que incluem sub-sequências temporais, por exemplo) e/ou informações para recuperar períodos remotos (para inserção de anúncios-alvo em conteúdo de meios durante a repetição, por exemplo). Os períodos remotos podem ser também referidos como períodos externos. As Figuras 4-7, discutidas mais detalhadamente a seguir, mostram diversos exemplos de conteúdo de multimídia com diversos elementos incluídos em uma ou outra de uma MPD e/ou representações (tal como dentro de segmentos de representações ou dados de cabeçalho de representações). Qualquer uma ou todas as MPDs das Figuras 4-7 podem corresponder substancialmente à MPD 102 da Figura 4.

[00145] De acordo com as técnicas desta invenção, a MPD 102 da Figura 4 pode especificar informações tais como, por exemplo, um gabarito de URL para faixas de bytes, se o gabarito é necessário ou opcional e critérios de seleção de CDN. Elementos exemplares de uma especificação de Tipo de MPD de acordo com as técnicas desta invenção são apresentados no pseudocódigo XML abaixo:  <xs:complexType name=“MPDtype”> <xs:sequence> <xs:element name=“ProgramInformation” type=“ProgramInformationType” minOccurs=“0”/> <xs:element name=“Period” type=“PeriodType” maxOccurs=“unbounded”/> <xs:element name=“BaseURL” type=“BaseURLType” minOccurs=“0” maxOccurs=“unbounded”/> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:attribute name=“redirectionUrl” type=“xs:anyURI”/> <xs:attribute name=“selectionAttribute” type=“xs:string”/> <xs:attribute name=“profiles” type=“URIVectorType”/> <xs:attribute name=“type” type=“PresentationType” default=“OnDemand”/> <xs:attribute name=“availabilityStartTime” type=“xs:dateTime”/> <xs:attribute name=“availabilityEndTime” type=“xs:dateTime”/> <xs:attribute name=“mediaPresentationDuration” type=“xs:duration”/> <xs:attribute name=“minimumUpdatePeriodMPD” type=“xs:duration”/> <xs:attribute name=“minBufferTime” type=“xs:duration”/> <xs:attribute name=“timeShiftBufferDepth” type=“xs:duration”/> <xs:anyAttribute namespace=“##other” processContents=“lax”/> </xs:complexType>

[00146] Desta maneira, a MPD 102 pode incluir dados que indicam um URL de redirecionamento para o conteúdo de multimídia 100. Conforme descrito acima com relação à Figura 3, o URLBase pode ser redirecionado para uma das CDNs 92. Ou seja, o dispositivo cliente 40 pode submeter um POST de HTTP ao URL de redirecionamento, que pode corresponder ao dispositivo servidor de redirecionamento 94. O dispositivo cliente 40 pode receber uma resposta do dispositivo servidor de redirecionamento 94, de modo que a resposta inclua informações que indicam um novo URL para receber dados de uma das representações 110-120 do conteúdo de multimídia 100, com base no URLBase. Em particular, o URLBase pode ser utilizado para selecionar uma CDN apropriada das CDNs 92.

[00147] Além do mais, de acordo com o pseudocódigo exemplar acima, a MPD 102 pode incluir dados que indicam um atributo de seleção. Conforme discutido acima, o atributo de seleção pode incluir dados numéricos que representam critérios de seleção, que podem ou não ser acompanhados de argumentos para URLsBase. Por conseguinte, o dispositivo cliente 40 ou um dispositivo proxy, tal como o dispositivo de cache proxy 82 (Figura 2), pode utilizar dados do atributo de seleção de modo a selecionar uma CDN apropriada das CDNs 92 (Figura 3) da qual fazer com que o dispositivo cliente 40 recupere dados para o conteúdo de multimídia 100.

[00148] O pseudocódigo XML apresenta provê um conjunto exemplar de elementos para informações de acesso a segmentos pré-definidos, que pode ser apresentado na MPD 102.  <xs:complexType name=“SegmentInfoDefaultType”> <xs:sequence> <xs:element name=“InitialisationSegmentURL” type=“UrlType” minOccurs=“0”/> <xs:element name=“BaseURL” type=“BaseURLType” minOccurs=“0” maxOccurs=“unbounded”/> <xs:element name=“SegmentTimeline” type=“SegmentTimelineType” minOccurs=“0”/> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:attributeGroup ref=“SegmentInfoAttrGroup”/> <xs:attribute name=“sourceURLTemplatePeriod” type=“xs:string”/> <xs:attribute name=“indexTemplate” type=“xs:string”/> <xs:anyAttribute namespace=“##other” processContents=“lax”/> </xs:complexType>

[00149] O pseudocódigo XML abaixo apresenta um conjunto exemplar de elementos para informações de acesso a segmentos, que pode ser fornecido pela MPD 102.  <xs:complexType name=“SegmentInfoType”> <xs:sequence> <xs:element name=“InitialisationSegmentURL” type=“UrlType” minOccurs=“0”/> <xs:element name=“BaseURL” type=“BaseURLType” minOccurs=“0” maxOccurs=“unbounded”/> <xs:element name=“SegmentTimeline” type=“SegmentTimelineType” minOccurs=“0”/> <xs:choice minOccurs=“0”> <xs:element name=“UrlTemplate” type=“UrlTemplateType” minOccurs=“0”/> <xs:element name=“ByteRangeTemplate” type=“ByteRangeTemplateType” minOccurs=“0”/> <xs:sequence> <xs:element name=“Url” type=“UrlType” maxOccurs=“unbounded”/> <xs:element name=“Index” type=“UrlType” maxOccurs=“unbounded”/> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:element name=“SegmentList” type=“SegmentListType” minOccurs=“0”/> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:choice> </xs:sequence> <xs:attributeGroup ref=“SegmentInfoAttrGroup”/> <xs:anyAttribute namespace=“##other” processContents=“lax”/> </xs:complexType>

[00150] Desta maneira, a MPD 102 pode incluir dados que representam um gabarito de URL, que podem especificar como dispositivos de cliente, tais como o dispositivo cliente 40, podem estruturar um URL em uma solicitação para OBTER HTTP de modo a solicitar uma faixa de bytes dentro do URL propriamente dito, e não com um cabeçalho “Faixa:”. Por conseguinte, o dispositivo cliente 40 pode utilizar dados da MPDD 102 para construir uma solicitação para OBBTER HTTP que especifique uma faixa de bytes dentro de um URL, em vez de utilizar um cabeçalho “Faixa:”. Portanto, embora a solicitação seja construída como uma solicitação para OBTER HTTP, a solicitação pode fazer com que um dispositivo servidor, tal como o dispositivo servidor 60, forneça apenas a faixa de bytes solicitada especificada pelo URL propriamente dito. Ou seja, em vez de prover todos os dados do URL, o dispositivo servidor 60 pode em vez disso prover a faixa de bytes solicitada dentro do URL propriamente dito. Assim, o dispositivo servidor 60 não precisa avaliar os dados que se seguem a um cabeçalho “Faixa:”, mas pode, em vez disso, determinar a faixa de bytes solicitada do URL propriamente dito. Da mesma maneira, o dispositivo de cache proxy 82 pode ser configurado para analisar URLs de solicitações para OBTER HTTP e para armazenar em cache e prover a faixa de bytes solicitação dentro do URL ao dispositivo cliente 40, concatenando ao mesmo tempo a faixa de bytes solicitada com faixas de bytes anteriores e/ou subsequentes do mesmo arquivo.

[00151] O pseudocódigo XML abaixo apresenta um conjunto exemplar de elementos para agrupar atributos que são comuns a SegmentInfo e SegmentInfoDefault, que pode ser fornecido pela MPD 102. Exemplos de SegmentInfo e SegmentInfoDefault incluem: < !-- grouping attributes common to SegmentInfo and SegmentInfoDefault --> <xs:attributeGroup name=“SegmentInfoAttrGroup” > <xs:attribute name=“duration” type=“xs:duration”/> <xs:attribute name=“startIndex” type=“xs:unsignedInt” default=“1”/> </xs:attributeGroup>

[00152] O pseudocódigo XML abaixo apresenta um conjunto exemplar de elementos para um URL de segmentos, que pode ser fornecido pela MPD 102. < !-- A Segment URL --> <xs:complexType name=“UrlType”> <xs:sequence> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:attribute name=“sourceURL” type=“xs:anyURI”/> <xs:attribute name=“range” type=“xs:string”/> <xs:anyAttribute namespace=“##other” processContents=“lax”/> </xs:complexType>

[00153] O pseudocódigo XML abaixo apresenta um conjunto exemplar de elementos para um gabarito de URL, que pode ser fornecido pela MPD 102. < !-- A URL template --> <xs:complexType name=“UrlTemplateType”> <xs:sequence> <xs:any namespace=“##other” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:attribute name=“sourceURL” type=“xs:anyURI”/> <xs:attribute name=“indexURL” type=“xs:anyURI”/> <xs:attribute name=“endIndex” type=“xs:unsignedInt”/> <xs:attribute name=“byteRangeTemplate” type=“xs:string” > <xs:attribute name=“mustUseRangeURL” type=“xs:unsignedInt”> <xs:attribute name=“allowedByteRanges” type=“xs:unsignedInt”> <xs:anyAttribute namespace=“##other” processContents=“lax”/> </xs:complexType>

[00154] Desta maneira, a MPD 102 pode incluir informações que indicam um gabarito de URL. Ou seja, o elemento GabaritoDeFaixaDeBytes representa dados para um gabarito de URL para especificar uma faixa de bytes solicitada. Além do mais, desta maneira, a MPD 102 pode incluir informações que indicam se a utilização do gabarito é necessária ou opcional. Ou seja, os dados para deveUtilizarURLDeFaixa podem indicar se ao dispositivo cliente 40 é permitido solicitar uma faixa de bytes utilizando solicitações de OBTENÇÃO de HTTP parciais ou o gabarito, ou se ao dispositivo cliente 40 é exigida a utilização do gabarito. Além disto, os dados para FaixasDeBytesPermitidas podem indicar faixas de bytes específicas que podem ser solicitadas ou se não há restrições a faixas de bytes.

[00155] O pseudocódigo XML abaixo apresenta um conjunto exemplar de elementos para uma lista de segmentos, que pode ser fornecido pela MPD 102. < !-- SegmentList allows xlink in addition to list of URLs --> <xs:complexType name=“SegmentListType”> <xs:sequence> <xs:element name=“Url” type=“UrlType” minOccurs=“0” maxOccurs=“unbounded”/> <xs:element name=“Index” type=“UrlType” minOccurs=“0” maxOccurs=“unbounded”/> </xs:sequence> <xs:attribute ref=“xlink:href”/> <xs:attribute ref=“xlink:actuate” default=“onRequest”/> <xs:attribute name=“startIndex” type=“xs:unsignedInt”/> </xs:complexType>

[00156] Os dados de cabeçalho 112, quando presentes, podem descrever características dos segmentos 114, como, por exemplo, as localizações temporais de pontos de acesso aleatório, segmentos 114 esses que incluem pontos de acesso aleatório, deslocamentos de bytes para pontos de acesso aleatório dentro dos segmentos 114, localizadores de recursos uniformes (URLs) dos segmentos 114 ou outros aspectos dos segmentos 114. Os dados de cabeçalho 122, quando presentes, podem descrever características dos segmentos 124. Além disso ou alternativamente, tais características podem ser completamente incluídas dentro da MPD 102.

[00157] Os segmentos 114 incluem uma ou mais amostras de vídeo codificadas, cada uma das quais pode incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas dos segmentos 114 pode ter características semelhantes, como, por exemplo, requisitos de altura, largura e largura de banda. Tais características podem ser descritas pelos dados da MPD 102, embora tais dados não sejam mostrados no exemplo da Figura 4. A MPD 102 pode incluir as características descritas pela Especificação 3GPP, com o acréscimo de qualquer uma ou de todas as informações sinalizadas descritas nesta invenção.

[00158] Cada um dos segmentos 114, 124 pode ser associado a um identificador de recursos uniformes (URI) único, como, por exemplo, um localizador de recursos uniformes (URL). Assim, cada um dos segmentos 114, 124 pode ser recuperado de maneira independente utilizando-se um protocolo de rede de fluxo contínuo, tal como o DASH. Desta maneira, um dispositivo de destino, tal como o dispositivo cliente 40, pode utilizar uma solicitação para Obter HTTP de modo a recuperar os segmentos 114 ou 124. Em alguns exemplos, o dispositivo cliente 40 pode utilizar solicitações para OBTER HTTP parciais de modo a recuperar faixas de bytes específicas dos segmentos 114 ou 124.

[00159] Conforme observado acima, a MPD 102 pode conformar-se a um perfil de MPD específico. A MPD 102 pode incluir informações que indicam um tipo de Extensão de Correio da Internet com Várias Finalidades (MIME) para a MPD 102 e/ou para o conteúdo de multimídia 100. Entretanto, os tipos de MIME geralmente não indicam qual codec é necessário para apresentar conteúdo de multimídia. Em geral, supõe-se que, se um dispositivo puder recuperar uma MPD para conteúdo de multimídia, tal como a MPD 102, o dispositivo pode repetir os dados do conteúdo de multimídia que correspondem à MPD. Entretanto, esta suposição nem sempre pode ser certa. Portanto, em alguns exemplos, a MPD 102 pode incluir informações que indicam o perfil ao qual a MPD corresponde.

[00160] Pode haver um número relativamente pequeno de perfis aos quais as MPDs podem corresponder. Os perfis podem ser suportados por níveis para atender às capacidades, de maneira semelhante à maneira pela qual o H.264/AVC inclui perfis e níveis para codificação de vídeo. Os perfis de MPD podem ser em forma de invólucros semelhantes a cebolas, no sentido de que um perfil mais elevado pode incluir todos os recursos de todos os perfis mais baixos. Pode haver um processo de registro junto a uma autoridade de registro para o registro de diversos perfis. Em alguns exemplos, um dispositivo cliente, tal como o dispositivo cliente 40, pode ser configurado pare recuperar informações que indicam o perfil para a MPD, tal como a MPD 102, antes de recuperar outros dados da MPD, tais como as características das representações 110-120 sinalizadas pela MPD 2. Desta maneira, o perfil para a MPD 102 pode ser sinalizado antes que seja dado acesso à MPD 102.

[00161] Um identificador de perfil pode ser fornecido em texto simples (como um nome simples, por exemplo) ou em um nome de domínio invertido. Nomes simples podem ser reservados por uma autoridade de registro, tal como uma autoridade 3GPP ou outra autoridade de registro. Um perfil pode ser considerado uma reivindicação e uma permissão, no sentido de que o perfil pode reivindicar que o conteúdo de multimídia correspondente se conforme a um perfil e dê permissão ao leitor (um dispositivo cliente, por exemplo) que implementa esse perfil para ler a MPD, interpretar o que reconhece e ignorar o material que não compreende.

[00162] Os perfis podem descrever características tais como, por exemplo, os recursos da MPD 102, a utilização da rede, o(s) formato(s) dos meios, o(s) codec(s) utilizado(s), o(s) formato(s) de proteção e/ou medidas quantitativas tais como taxas de bits, tamanhos de tela e semelhantes. Desta maneira, o perfil da MPD 102 pode informações que indicam quais codecs é necessário suportar para recuperação dos dados da MPD 102 e/ou do conteúdo de multimídia 100. Os perfis podem ser também descritos como “pontos de conformação”. Os perfis com os quais uma MPD se conforma podem ser indicados no atributo “Perfis” da MPD. Assim, um dispositivo cliente pode ser configurado para recuperar uma parte da MPD 102 que inclui informações referentes ao atributo “Perfis” antes de recuperar dados adicionais da MPD 102. Alternativamente, os perfis podem ser indicados como um parâmetro no tipo de MIME da MPD. Por exemplo, os perfis “X, Y e Z” podem ser sinalizados pelo dispositivo de preparação de conteúdo 20, por exemplo, da maneira seguinte: video/vnd.mpeg.mpd;profile=“X,Y,Z”.

[00163] A Figura 5 é um diagrama de blocos que mostra elementos de um arquivo de vídeo 150 exemplar, que pode corresponder a um segmento de uma representação, tal como um dos segmentos 114, 124 da Figura 4. Cada um dos segmentos 114, 124 pode incluir dados que se conformam substancialmente à disposição de dados mostrada no exemplo da Figura 5. Conforme descrito acima, os arquivos de vídeo

[00164] de acordo com o formato de meios base ISO e extensões dele armazenam dados em uma série de objetos, referidos como “caixas”. No exemplo da Figura 5, o arquivo de vídeo 150 inclui uma caixa de tipos de arquivo (FTYP) 152, uma caixa de filmes (MOOV) 154, fragmentos de filme 162 (também referidos como caixas de fragmentos de filme (MOOF)) e uma caixa de acesso aleatório a fragmentos de filme (MFRA) 164.

[00165] O arquivo de vídeo 150 representa geralmente um exemplo de segmento de conteúdo de multimídia, que pode ser incluído em uma das representações 110-120 (Figura 4). Desta maneira, o arquivo de vídeo 150 pode corresponder a um dos segmentos 114, a um dos segmentos 124 ou a um segmento de outra representação. De acordo com as técnicas desta invenção, um dispositivo cliente, tal como o dispositivo cliente 40, pode solicitar a recuperação de um subconjunto de fragmentos de filme 162 utilizando um URL que especifica uma faixa de bytes. A faixa de bytes pode corresponder a uma sub-sequência de fragmentos de filme 162. Da mesma maneira, um dispositivo de cache proxy, tal como o dispositivo de cache proxy 82, pode recuperar todos os dados do arquivo de vídeo 150 em resposta a uma solicitação de recuperação de uma faixa de bytes específica. Em outros exemplos, o dispositivo de cache proxy 82 pode montar o arquivo de vídeo 150 em seguida a um conjunto de solicitações de faixas de bytes do arquivo de vídeo 150, supondo-se que o conjunto de solicitações corresponda à quantidade de dados para o arquivo de vídeo 150.

[00166] No exemplo da Figura 5, o arquivo de vídeo 150 inclui uma caixa de índices de segmento (SIDX) 161. Em alguns exemplos, o arquivo de vídeo 150 pode incluir caixas SIDX, como, por exemplo, entre os fragmentos de filme 162. Em geral, as caixas SIDX, tais como a caixa SIDX 161, incluem informações que descrevem faixas de bytes para um ou mais dos fragmentos de filme 162. Em outros exemplos, a caixa SIDX 161 e/ou outras caixas SIDX podem ser apresentadas dentro da caixa MOOV 154, em seguida à caixa MOOV 154, precedendo ou seguindo-se à caixa MFRA 164 ou em outro lugar dentro do arquivo de vídeo 150.

[00167] A caixa de tipos de arquivo (FTYP) 152 descreve geralmente o tipo de arquivo para o arquivo de vídeo 150. A caixa de tipos de arquivo 152 pode incluir dados que identificam uma especificação que descreve o melhor uso para o arquivo de vídeo 150. A caixa de tipos de arquivo 152 pode ser colocada antes da caixa MOOV 154, das caixas de fragmentos de filme 162 e da caixa MFRA 164.

[00168] A caixa MOOV 154, no exemplo da Figura 5, inclui uma caixa de cabeçalhos de filme (MVID) 156, uma caixa de trilhas (TRAK) 158 e uma ou mais caixas de extensões de filme (MVEX) 160. Em geral, a caixa MVHD 156 pode descrever as características gerais do arquivo de vídeo 150. Por exemplo, a caixa MVHD 156 pode incluir dados que descrevem quando o arquivo de vídeo 150 foi criado originalmente, quando o arquivo de vídeo foi modificado pela última vez, a escala de tempo para o arquivo de vídeo 150, a duração de repetição para o arquivo de vídeo 150 ou outros dados que descrevem geralmente o arquivo de vídeo 150.

[00169] A caixa TRAK 158 pode incluir dados para uma trilha do arquivo de vídeo 150. A caixa TRAK 158 pode incluir uma caixa de cabeçalhos de trilho (TKHD), que descreve as características da trilha que correspondem à caixa TRAK 158. Em alguns exemplos, a caixa TRAK 158 pode incluir imagens de vídeo codificadas, enquanto que, em outros exemplos, as imagens de vídeo codificadas da trilha podem ser incluídas nos fragmentos de filme 162, que podem ser referidos pelos dados da caixa TRAK 158.

[00170] Em alguns exemplos, o arquivo de vídeo 150 pode incluir mais de uma trilha, embora isto não seja necessário que o protocolo DASH funcione. Por conseguinte, a caixa MOOV 154 pode incluir um número de caixas TRAK igual ao número de trilhas no arquivo de vídeo 150. A caixa TRAK 158 pode descrever as características de uma trilha correspondente do arquivo de vídeo 150. Por exemplo, a caixa TRAK 158 pode descrever informações temporais e/ou espaciais para a trilha correspondente. Uma caixa TRAK semelhante à caixa TRAK 158 da caixa MOOV 154 pode descrever as características de uma trilha de conjunto de parâmetros, quando a unidade de encapsulamento 30 (Figura 1) inclui uma trilha de conjunto de parâmetros em um arquivo de vídeo, tal como o arquivo de vídeo 150. A unidade de encapsulamento 30 pode sinalizar a presença de mensagens SEI ao nível de sequência na trilha de conjunto de parâmetros dentro da caixa TRAK que descreve a trilha de conjunto de parâmetros.

[00171] As caixas MVEX 160 podem descrever as características de fragmentos de filme 162 correspondentes, como, por exemplo, para sinalizar que o arquivo de vídeo 150 inclui fragmentos de vídeo 162, além dos dados de vídeo incluídos na caixa MOOV 154, se existentes. No contexto do fluxo contínuo de dados de vídeo, imagens de vídeo codificadas podem ser incluídas nos fragmentos de filme 162 e não na caixa MOOV 154. Por conseguinte, todas as amostras de vídeo codificadas podem ser incluídas nos fragmentos de filme 162, e não na caixa MOOV 154.

[00172] A caixa MOOV 154 pode incluir um número de caixas MOOV 160 igual ao número de fragmentos de filme 162 no arquivo de vídeo 150. Cada uma das caixas MVEX 160 pode descrever as características de um fragmento de filme correspondente dos fragmentos de filme 162. Por exemplo, cada caixa MVEX pode incluir uma caixa de cabeçalhos de extensões de filme (MEHD), que descreve a duração temporal para o fragmento de filme correspondente dos fragmentos de filme 162.

[00173] Conforme mencionado acima, a unidade de encapsulamento 30 pode armazenar um conjunto de dados sequenciais em uma amostra de vídeo que não inclui dados de vídeo codificados reais. Uma amostra de vídeo pode corresponder geralmente a uma unidade de acesso, que representa uma imagem codificada em uma ocorrência de tempo específica. No contexto da AVC, a imagem codificada inclui uma ou mais unidades NAL VCL, que contêm as informações para construir todos os pixels da unidade de acesso e de outras unidades NAL não VCL, tais como mensagens SEI. Por conseguinte, a unidade de encapsulamento 30 pode incluir um conjunto de dados sequenciais, que pode inclui mensagens SEI ao nível de sequência, em um dos fragmentos de filme 162. A unidade de encapsulamento 30 pode sinalizar também a presença de um conjunto de dados sequenciais e/ou mensagens SEI ao nível de sequência como estando presentes em um dos fragmentos de filme 162 dentro de uma das caixas MVEX 160 que corresponde a um dos fragmentos de filme 162.

[00174] Os fragmentos de filme 162 podem incluir uma ou mais imagens de vídeo codificadas. Em alguns exemplos, os fragmentos de filme 162 podem incluir um ou mais grupos de imagens (GOPs), cada um dos quais pode incluir várias imagens de vídeo codificadas, como, por exemplo, quadros ou imagens. Além disto, conforme descrito acima, os fragmentos de filme 162 podem incluir conjuntos de dados sequenciais em alguns exemplos. Cada um dos fragmentos de filme 162 pode incluir uma caixa de cabeçalhos de fragmentos de filme (MFHD, não mostrada na Figura 5). A caixa MFHD pode descrever as características do fragmento de filme correspondente, tais como o número de sequência para o fragmento de filme. Os fragmentos de filme 162 podem ser incluídos na ordem dos números de sequência no arquivo de vídeo 150.

[00175] A caixa MFRA 164 pode descrever os pontos de acesso aleatório dentro dos fragmentos de filme 162 do arquivo de vídeo 150. Isto pode ajudar na execução de modos artificiais, tais como a realização de buscas em localizações temporais dentro do arquivo de vídeo 150. A caixa MFRA 164 é geralmente opcional e não é necessário incluí-la em arquivos de vídeo, em alguns exemplos. Da mesma maneira, um dispositivo cliente, tal como o dispositivo cliente 40, não tem necessariamente que referir a caixa MFRA 164 para decodificar corretamente e exibir os dados de vídeo do arquivo de vídeo 150. A caixa MFRA 164 pode incluir um número de caixas de acesso aleatório a fragmentos de trilha (TFRA) (não mostradas) igual ao número de trilhas do arquivo de vídeo 150 ou, em alguns exemplos, igual ao número de trilhas de meios (trilhas não alusivas, por exemplo) do arquivo de vídeo 150.

[00176] A Figura 6 é um fluxograma que mostra um método exemplar para prover indicações de dados de gabarito de URL e para gerar solicitações de faixa de bytes utilizando os dados de gabarito de URL por um dispositivo cliente. Embora o método da Figura 6 seja descrito com relação ao dispositivo servidor 60 e ao dispositivo cliente 40, deve ficar entendido que outros dispositivos podem implementar técnicas semelhantes às do método da Figura 6. Por exemplo, o dispositivo de preparação de conteúdo 20 ou um ou mais dispositivos de rede de uma rede de distribuição de conteúdo, tais como o dispositivo de cache proxy 82 ou os dispositivos de roteamento 80, podem desempenhar algumas ou todas as funções atribuídas ao dispositivo servidor 60.

[00177] Embora não mostrado na Figura 6, em alguns exemplos o dispositivo cliente 40 pode determinar inicialmente uma CDN da qual solicitar conteúdo de multimídia. Em alguns exemplos, o dispositivo cliente 40 pode selecionar a CDN de uma pluralidade de CDNs, enquanto que, em outros exemplos, um servidor de redirecionamento, tal como o dispositivo servidor de redirecionamento 94, pode selecionar uma CDN e prover informações ao dispositivo cliente 40 que indicam a CDN selecionada. Por conseguinte, o dispositivo cliente 40 pode selecionar uma CDN ou receber uma indicação de CDN de modo a determinar a CDN da qual solicitar dados de conteúdo de multimídia. Um processo exemplar para selecionar uma CDN é explicado mais detalhadamente a seguir com relação à Figura 9.

[00178] O dispositivo servidor 60 pode prover indicações de conjuntos de adaptações e dados de gabarito de URL ao dispositivo cliente 40 (200). Por exemplo, o dispositivo servidor 60 pode prover a MPD 102 (Figura 4) ao dispositivo cliente 40. Conforme discutido acima, a MPD 102 pode incluir informações que representam um gabarito de URL, assim como se o gabarito é necessário ou opcional para solicitações de faixa de bytes. O dispositivo cliente 40 pode receber informações que descrevem as características dos conjuntos de adaptações (202), como, por exemplo, do arquivo de MPD recebido do dispositivo servidor 60. Da mesma maneira, o dispositivo cliente 40 pode receber informações que descrevem um gabarito de URL e se a utilização do gabarito é necessária ou opcional para solicitar faixas de bytes, do arquivo de MPD, por exemplo.

[00179] O dispositivo cliente 40 pode analisar então as características dos conjuntos de adaptações de modo a eliminar os conjuntos de adaptações que o dispositivo cliente 40 não pode ou não escolheria para recuperar, decodificar ou renderizar. Por exemplo, o dispositivo cliente 40 pode comparar as capacidades de decodificação e renderização com as características dos conjuntos de adaptações de modo a determinar conjuntos de adaptações inapropriados. Como outro exemplo, o dispositivo cliente 40 pode comparar as preferências de usuário para linguagem, classificação e grau de profundidade (fornecidas por duas ou mais vistas que têm ângulos de câmera específicos para repetição de vídeo tridimensional, por exemplo), de modo a eliminar conjuntos de adaptações indesejáveis. O dispositivo cliente 40 pode selecionar então um conjunto de adaptações apropriado com base, pelo menos em parte, nas capacidades de decodificação e renderização do dispositivo cliente 40 (204).

[00180] Depois de selecionar um conjunto de adaptações, o dispositivo cliente 40 pode solicitar dados para uma parte da MPD que descreve especificamente as representações do conjunto de adaptações. Em resposta, o dispositivo servidor 60 pode prover indicações de taxas de bits das representações, entre outras características de representação individuais no conjunto de adaptações selecionado, ao dispositivo cliente 40 (206). Por exemplo, o dispositivo servidor 60 pode enviar dados para uma parte específica das partes da MPD para os conjuntos de adaptações 260 (Figura 6) ao dispositivo cliente 40. Em outros exemplos, o dispositivo cliente 40 já pode ter recebido uma MPD completa para o conteúdo de multimídia (a MPD 202 da Figura 5, por exemplo), mas pode analisar particularmente partes da MPD que correspondem especificamente ao conjunto de adaptações selecionado. Desta maneira, em alguns exemplos a etapa 206 da Figura 6 pode ocorrer antes da etapa 202 e/ou da etapa 204.

[00181] Seja como for, depois de receber as características específicas das representações do conjunto de adaptações selecionado, que incluem taxas de bits para as representações (208), o dispositivo cliente 40 pode determinar a quantidade atualmente disponível de largura de banda de rede (210). O dispositivo cliente 40 pode selecionar então uma representação do conjunto de adaptações selecionado (212), de modo que a representação selecionada tenha uma taxa de bits que possa ser acomodada pela quantidade de atualmente disponível de largura de banda de rede determinada. As taxas de bits das representações representam exemplos das características de codificação das representações individuais no conjunto de adaptações. O dispositivo cliente 40 pode então solicitar dados da representação selecionada utilizando o gabarito de URL (214).

[00182] Por exemplo, o dispositivo cliente 40 pode construir uma solicitação para OBTER HTTP de modo a solicitar um segmento da representação selecionada, onde uma URL na solicitação para OBTER HTTP especifica a faixa de bytes de dados a ser solicitada. Alternativamente, o dispositivo cliente 40 pode construir uma OBTENÇÃO de HTTP parcial que especifica uma faixa de bytes de um segmento da representação selecionada, supondo-se que solicitações de OBTENÇÃO parciais sejam permitidas (isto é, que a utilização do gabarito de URL seja opcional). Em alguns exemplos, os dados de gabarito de URL podem especificar também faixas de bytes específicas que são permissíveis. Em tais casos, o dispositivo cliente 40 pode selecionar uma das faixas de bytes disponíveis. Seja como for, o dispositivo cliente 40 pode submeter a solicitação a um URLBase, o que pode fazer com que a solicitação seja recebida por um dispositivo proxy ou dispositivo de cache, que pode servir a solicitação no lugar de um dispositivo servidor.

[00183] No exemplo da Figura 6, o dispositivo servidor 60 pode receber a solicitação e, em resposta, enviar os dados solicitados ao dispositivo cliente 40 (216). Por exemplo, a unidade de processamento de solicitações 70 pode determinar o endereço rede do dispositivo cliente a partir dos dados da solicitação recebida, como, por exemplo, o endereço de protocolo Internet (IP) de origem e a porta de origem da solicitação recebida. A unidade de processamento de solicitações 70 pode formar pacotes de rede que incluem os dados solicitados e enviar ao dispositivo cliente 40 os dados solicitados, destinados ao endereço IP determinado do dispositivo cliente, por exemplo.

[00184] Depois de receber os dados solicitados, o dispositivo cliente 40 pode começar a decodificar e exibir os dados recebidos (218). Enquanto recebe os dados solicitados, o dispositivo cliente 40 pode continuar a analisar a largura de banda de rede atualmente disponível e submeter solicitações de representações que têm taxas de bits que podem ser acomodadas pela quantidade atualmente disponível de largura de banda de rede (210-214). Se a quantidade de largura de banda de rede se alterar, o dispositivo cliente 40 pode comutar seletivamente para uma representação diferente no conjunto de adaptações selecionado. Por exemplo, o dispositivo cliente 40 pode determinar um segmento em uma nova representação que corresponde à localização temporal do último segmento solicitado de uma representação anterior no conjunto de adaptações, em seguida solicitar o segmento determinado (ou uma parte dele) na nova representação.

[00185] Desta maneira, a Figura 6 representa um exemplo de método para recuperar dados de multimídia que inclui determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[00186] A Figura 6 representa um exemplo de método para enviar informações para dados de vídeo, que inclui prover um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes (URL) e um gabarito de faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL de modo a incluir uma solicitação de faixa de bytes dentro do URL, receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que o URL da solicitação especifica a faixa de bytes de uma representação do conteúdo de multimídia e, em resposta à solicitação, transmitir dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

[00187] A Figura 7 é um fluxograma que mostra um método exemplar para gerar uma solicitação de OBTENÇÃO que especifica uma faixa de bytes em um URL. O método da Figura 7 pode ser executado por um dispositivo cliente, tal como o dispositivo cliente 40. As caixas com linhas tracejadas representam etapas opcionais. Um método semelhante pode ser executado por um dispositivo de rede intermediário, tal como o dispositivo de cache proxy 82. Algumas ligeiras modificações no método podem ser feitas quando executado por um dispositivo de rede intermediário, conforme discutido a seguir. Para fins de exemplificação, o método da Figura 7 é descrito com relação ao dispositivo cliente 40. Em alguns exemplos, as etapas 230-234 podem ser executadas de maneira substancialmente contemporânea com as etapas 202 e 204 da Figura 6, e as etapas 236-234 podem corresponder à etapa 214 da Figura 6. Não é necessário que as etapas das Figuras 6 e 7 sejam executadas na ordem mostrada, e etapas adicionais podem ser executadas ou determinadas etapas podem ser omitidas ou executadas em paralelo, e não sequencialmente.

[00188] Inicialmente, o dispositivo cliente 40 pode receber informações que correspondem a um arquivo de MPD para conteúdo de multimídia (230). O arquivo de MPD pode incluir informações que especificam um gabarito de URL para embutir uma faixa de bytes no URL de uma solicitação para OBTER HTTP. Por exemplo, o gabarito de URL pode especificar, para os gabaritos tanto de URL quanto de faixa de bytes, o seguinte: GabaritoDeURL = http://www.mp4player.com/TRON/segment.$Bandwidth$ Indez$ GabaritoDeFaixaDeBytes = “$Url$StartByte$EndByte$

[00189] O arquivo de MPD pode incluir informações que indicam se o gabarito de URL é necessário ou opcional. Por conseguinte, o dispositivo cliente 40 pode, em alguns exemplos, determinar se o gabarito de URL é necessário ou opcional (232), com base em uma análise dos dados do arquivo de MPD. Da mesma maneira, em alguns exemplos o arquivo de MPD pode prover uma indicação de faixas de bytes permitidas que podem ser solicitadas, ou pode indicar que as faixas de bytes não são restritas. Assim, o dispositivo cliente 40 pode utilizar o arquivo de MPD para determinar faixas de bytes permitidas, em alguns exemplos (234).

[00190] O dispositivo cliente 40 pode em seguida determinar a faixa de bytes de um segmento a ser solicitado (236). Por exemplo, se o dispositivo cliente 40 tiver apenas iniciado a execução do fluxo contínuo dos dados do conteúdo de multimídia, o dispositivo cliente 40 pode determinar a solicitação de uma primeira faixa de bytes ordinal do segmento. Como outro exemplo, se o dispositivo cliente 40 tiver solicitado anteriormente a Na faixa de bytes do segmento, o dispositivo cliente 40 pode determinar a solicitação da N+1a faixa de bytes do segmento. O dispositivo cliente 40 pode determinar também um URL base para a representação selecionada, assim como um identificador de segmento (238). Conforme discutido acima, por exemplo, o URL base pode corresponder a http://www.mp4player.com/TRON/ e o identificador de segmento pode compreender um valor numérico, alfabético, alfanumérico ou outro valor que representa o segmento atual. O identificador de segmento pode identificar o segmento, assim como uma representação selecionada na qual o segmento é incluído. Por exemplo, o identificador de segmento pode incluir valores que especificam a largura de banda e/ou o índice da representação selecionada, assim como um valor que especifica o segmento da representação selecionada.

[00191] Assim, o URL base e o identificador de segmento podem formar juntos uma primeira parte do URL que o dispositivo cliente 40 incluirá finalmente em uma solicitação para OBTER HTTP de modo a recuperar a faixa de bytes seguinte. O dispositivo cliente 40 pode anexar o ID de segmento, assim como um identificador da faixa de bytes a ser solicitada, ao URL base (240), formando um URL a ser incluído em uma solicitação para OBTER HTTP. Por exemplo, supondo-se que o segmento seja identificado utilizando-se o “segmento.1000.27” e supondo-se que a faixa de bytes a ser solicitada tenha os bytes 435291 a 560829, o dispositivo cliente 40 pode anexar “segmento.1000.27/435291/560829” ao URL base, formando o URL seguinte neste exemplo: http://mp4player.com/TRON/segment.1000.27/435291/560929”. Este URL corresponde à parte de percurso de arquivo de um URL. Outra parte do URL pode especificar um protocolo, como, por exemplo, “HTTP/1.1”, ou outros dados para recuperar o arquivo no percurso de arquivo correspondente.

[00192] O dispositivo cliente 40 pode formar então uma solicitação para OBTER HTTP que inclui o URL construído (242). Por exemplo, o dispositivo cliente 40 pode especificar que a solicitação é uma solicitação de OBTENÇÃO pré-anexando o comando “OBTER” antes do URL e anexando “HTTP/1.1” depois do URL, assim como especificando o hospedeiro do conteúdo de multimídia, como, por exemplo, “www.mp4player.com”. Em alguns exemplos, o dispositivo cliente 40 pode formar a solicitação de modo a incluir a indicação de que uma faixa de bytes está contida no URL, utilizando o cabeçalho de extensão “X-Dash-FaixaDeBytes- URL” desta invenção, por exemplo. Assim, a solicitação de OBTENÇÃO construída com um URL que especifica uma faixa de bytes pode corresponder a: OBTER http://www.mp4player.com/TRON/segment.1000.27/435291/560829 HTTP/1.1 Hospedeiro: www.mp4player.com

[00193] O dispositivo cliente 40 pode enviar então a solicitação para OBTER HTTP formada ao servidor (244), como, por exemplo, www.mp4player.com. Conforme mencionado acima, um dispositivo de rede intermediário pode executar um método semelhante ao da Figura 7 de modo a formar uma solicitação para OBTER HTTP que inclui um URL que especifique uma faixa de bytes na parte de percurso de arquivo. Em geral, o dispositivo de rede intermediário pode receber o arquivo de MPD de modo a determinar um gabarito de URL para o conteúdo de multimídia do dispositivo servidor e pode receber uma solicitação para OBTER HTTP parcial de um dispositivo cliente. O dispositivo de rede intermediário pode utilizar então o gabarito de URL (que inclui o gabarito de faixa de bytes) de modo a formar uma solicitação para OBTER HTTP a partir da solicitação de OBTENÇÃO parcial, de modo que a solicitação para OBTER HTTP inclua um URL que especifique a faixa de bytes indicada pela solicitação de OBTENÇÃO parcial.

[00194] Desta maneira, o método da Figura 7 representa um exemplo de método para recuperar dados de multimídia. O método exemplar da Figura 7 inclui determinar a faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado de um dispositivo de origem, formar um localizador de recursos uniformes (URL) que especifica, na parte de percurso de arquivo do URL, o arquivo e a faixa de bytes de acordo com os requisitos do dispositivo de origem, e emitir uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

[00195] A Figura 8 é um fluxograma que mostra um método exemplar em que uma solicitação para OBTER HTTP é trocada entre um dispositivo cliente e um dispositivo servidor por meio de um dispositivo de rede intermediário. Este método exemplar é descrito com relação ao dispositivo cliente 40, ao dispositivo de cache proxy 82 e ao dispositivo servidor, embora deva ficar entendido que outros dispositivos podem ser configurados para executar um método semelhante.

[00196] No exemplo da Figura 8, o dispositivo cliente 40 seleciona uma representação de conteúdo de multimídia (250). Em seguida, o dispositivo cliente 40 forma uma solicitação para OBTER HTTP de acordo com um gabarito de URL (252), de modo que a solicitação para OBTER HTTP especifique uma faixa de bytes no URL da solicitação. O gabarito de URL pode incluir dados para um gabarito de faixa de bytes do URL. Em alguns exemplos, o dispositivo cliente 40 pode formar a solicitação de modo a incluir a indicação de que uma faixa de bytes está contida no URL, utilizando o cabeçalho “X-Dash-FaixaDeBytes-URL” desta invenção. Depois de formar a solicitação, o dispositivo cliente 40 pode submeter a solicitação para OBTER HTTP ao dispositivo servidor 60 (254).

[00197] O dispositivo de cache proxy 82 é disposto ao longo de uma rota de rede entre o dispositivo cliente 40 e o dispositivo servidor 60 neste exemplo, conforme mostrado na Figura 2, por exemplo. Por conseguinte, o dispositivo de cache proxy 82 pode receber a solicitação emitida pelo dispositivo cliente 40 (256). O dispositivo de cache proxy 82 pode determinar que a solicitação é uma solicitação de faixa de bytes analisando o URL da solicitação e emitir a solicitação para o dispositivo servidor 60 (258). Alternativamente, o dispositivo de cache proxy 82 pode determinar que a solicitação é uma solicitação de faixa de bytes ao detectar o cabeçalho de extensão “X-Dash-FaixaDeBytes-URL”. O dispositivo servidor 60 pode recuperar finalmente a solicitação (260) e enviar a faixa de bytes solicitada (262). Ou seja, o dispositivo servidor 60 fornece dados que correspondem à faixa de bytes solicitada do respectivo da representação de conteúdo de multimídia ao dispositivo cliente 40.

[00198] Novamente, o dispositivo de cache proxy 82 pode receber os dados da faixa de bytes solicitada (264), devido à localização do dispositivo de cache proxy 82 ao longo da rota entre o dispositivo cliente 40 e o dispositivo servidor 60. O dispositivo de cache proxy 82 pode adicionar então os dados recebidos a quaisquer dados armazenados em cache anteriormente do conteúdo de multimídia correspondente (266). Se nenhum dado não tiver sido ainda recebido, o dispositivo de cache proxy 82 pode formar um novo conjunto de dados, armazenado em cache localmente, para o conteúdo de multimídia. O dispositivo de cache proxy 82 pode também concatenar os dados recebidos em seguida para o conteúdo de multimídia com os dados atualmente armazenados em cache paro o conteúdo de multimídia. O dispositivo de cache proxy 82 pode também enviar os dados recebidos da faixa de bytes ao dispositivo cliente 40 (268). O dispositivo cliente 40 pode, por sua vez, armazenar, decodificar e exibir os dados recebidos (270).

[00199] Conforme observado com relação à Figura 7, em alguns exemplos um dispositivo de rede intermediário pode ser configurado para converter uma solicitação de OBTENÇÃO parcial em uma solicitação para OBTER HTTP que inclui um URL que especifica uma faixa de bytes. Para fazê- lo, o dispositivo cliente 40 criaria uma solicitação de OBTENÇÃO parcial no lugar da solicitação para OBTER HTTP da etapa 252. Em seguida, o dispositivo de cache proxy 82 pode converter a solicitação de OBTENÇÃO parcial entre as etapas 256 e 258, como, por exemplo, de acordo com um gabarito de URL e um gabarito de faixa de bytes. Alternativamente, o dispositivo de cache proxy 82 pode converter um cabeçalho “Faixa:” detectado no novo cabeçalho de extensão “X-Dash- FaixaDeBytes-URL”, de acordo com as técnicas desta invenção, que pode ser seguido pela faixa de bytes especificada originalmente da solicitação de OBTENÇÃO parcial.

[00200] A Figura 9 é um fluxograma que mostra um método exemplar para determinar uma CDN da qual recuperar dados de conteúdo de multimídia. A Figura 9 representa meramente um método exemplar. Conforme descrito acima, outros métodos para selecionar uma CDN são também possíveis, sem a utilização de um dispositivo servidor de redirecionamento, por exemplo. Por exemplo, o dispositivo cliente 40 pode ser configurado para receber e avaliar critérios de seleção em lugar de um dispositivo servidor de redirecionamento. Para fins de exemplificação, o método da Figura 9 é descrito com relação ao dispositivo cliente 40 e ao dispositivo servidor de redirecionamento 94.

[00201] Neste exemplo, supondo-se que o dispositivo cliente 40 já tenha recebido um arquivo de MPD, o dispositivo cliente 40 envia uma mensagem de POST ao dispositivo servidor de redirecionamento 94 (300). Um arquivo de MPD para o conteúdo de multimídia pode especificar um endereço para o dispositivo servidor de redirecionamento 94 em um URL de redirecionamento. Por conseguinte, o dispositivo cliente 40 pode enviar a mensagem de POST ao URL de redirecionamento, fazendo com que a mensagem de POST chegue finalmente ao dispositivo servidor de redirecionamento 94.

[00202] O dispositivo servidor de redirecionamento 94 pode receber a mensagem de post (302). Em resposta, o dispositivo servidor de redirecionamento 94 pode avaliar os critérios de seleção para selecionar uma CDN (304). Os critérios de seleção podem incluir qualquer um ou todos os critérios aleatórios ponderados, hora do dia, retardo de ida e volta entre o dispositivo cliente 40 e as CDNs, totais de saltos entre o dispositivo cliente e as CDNs, localizações do dispositivo cliente 40 e das CDNs ou outros critérios. Pela avaliação dos critérios de seleção, o dispositivo servidor de redirecionamento 94 pode determinar uma CDN a partir dos critérios de seleção (306). Além do mais, o dispositivo servidor de redirecionamento 94 pode ser configurado com dados que representam URLs base para o conteúdo de multimídia em cada uma das CDNs. Por conseguinte, o dispositivo servidor de redirecionamento 94 pode determinar o URL base para a CDN determinada (308).

[00203] O dispositivo servidor de redirecionamento 94 pode enviar então o URL base determinado ao dispositivo cliente 40 (310). Por conseguinte, o dispositivo cliente 40 pode formar uma solicitação para OBTER HTTP que especifica uma faixa de bytes específica (312), que pode especificar o URL base recebido. Além do mais, o dispositivo cliente 40 pode enviar a solicitação para OBTER HTTP ao novo URL base (314), fazendo com que a solicitação para OBTER HTTP seja direcionada para a CDN determinada. Ou seja, o dispositivo cliente 40 pode efetuar uma busca de serviço de nomes de domínio (DNS) no URL base de modo a determinar o endereço IP de um dispositivo da CDN para o qual emitir a solicitação de OBTENÇÃO e pode enviar então a solicitação de OBTENÇÃO ao endereço IP determinado. Em seguida, a CDN pode responder à solicitação de OBTENÇÃO com a faixa de bytes selecionada, e o dispositivo cliente 40 pode continuar submetendo uma série de solicitações de faixa de bytes à mesma CDN.

[00204] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação deles. Se implementadas em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código em um meio legível por computador e executadas por uma unidade de processamento baseada em hardware. Os meios passiveis de leitura por computador podem incluir meios de armazenamento passíveis de leitura por computador, que correspondem a meios tangíveis tais como meios de armazenamento de dados, ou meios de comunicação que incluem qualquer meio que facilite a transferência de um programa de computador de um lugar para outro, como, por exemplo, de acordo com um protocolo de comunicação. Desta maneira, um meio legível por computador pode corresponder geralmente a (1) um meio de armazenamento legível por computador tangível que é não transitório ou (2) um meio de comunicação, tal como um sinal ou onda portadora. O meio de armazenamento de dados pode ser qualquer meio disponível que possa ser acessado por um ou mais computadores ou um ou mais processadores para recuperar instruções, código e/ou estruturas de dados para implementação das técnicas descritas nesta invenção. Um produto de programa de computador pode incluir um meio legível por computador.

[00205] A título de exemplo, e não de limitação, tal meio legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou qualquer outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, memória flash ou qualquer outro meio que possa ser utilizado para armazenar código de programa desejado sob a forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Além disto, qualquer conexão é apropriadamente denominada de meio legível por computador. Por exemplo, se instruções forem transmitidas de um site da Web, servidor ou outra fonte remota utilizando-se um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio tais como infravermelho, rádio e microonda, então o cabo coaxial, o cabo de fibra óptica, o par trançado, a DSL ou tecnologias sem fio tais como infravermelho, rádio e microonda são incluídos na definição de meio. Deve ficar entendido, contudo, que meios de armazenamento passíveis de leitura por computador e meios de armazenamento de dados tangíveis não incluem conexões, ondas portadoras, sinais ou outros meios transitórios, mas em vez disso são direcionados para meios de armazenamento tangíveis, não transitórios. O termo disco (disk e disc), conforme aqui utilizado, inclui disco compacto (CD), disco de laser, disco óptico, disco versátil digital (DVD), disco flexível e disco blu-ray, em que usualmente discos (disks) reproduzem dados magneticamente, enquanto discos (discs) reproduzem dados opticamente com lasers. Combinações deles devem ser também incluídas dentro do alcance dos meios passíveis de leitura por computador.

[00206] As instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinais digitais (DSPs), microprocessadores de uso geral, circuitos integrados específicos de aplicativo (ASICs), arranjos lógicos programáveis no campo (FPGAs) ou outros circuitos de lógica integrada ou discreta equivalentes. Por conseguinte, o termo “processador”, conforme aqui utilizado, pode referir-se a qualquer uma das estruturas precedentes ou a qualquer outra estrutura adequada para implementação das técnicas aqui descritas. Além disto, sob alguns aspectos, a funcionalidade aqui descrita pode ser provida dentro de módulos de hardware e/ou software dedicados ou unidades de hardware configuradas para configurados para codificação e decodificação, ou incorporada a um codec combinado. Além disto, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.

[00207] As técnicas desta invenção podem ser implementadas em uma ampla variedade de dispositivos ou equipamentos, que incluem um dispositivo telefônico sem fio, um circuito integrado (IC) ou um conjunto de ICs (um conjunto de chips, por exemplo). Diversos componente, módulos ou unidades são descritos nesta invenção para enfatizar aspectos funcionais de dispositivos configurados para executar as técnicas reveladas, mas não exigem necessariamente a execução por unidades de hardware diferentes. Em vez disso, conforme descrito acima, diversas unidades podem ser combinadas em uma unidade de hardware de codec ou providas por uma coleção de unidades de hardware interoperantes, inclusive um ou mais processadores, conforme descrito acima, em conjunto com software e/ou firmware adequado.

[00208] Foram descritos diversos exemplos. Estes e outros exemplos estão dentro do alcance das reivindicações seguintes.

Claims

1. Método para recuperar dados de multimídia, o método compreendendo: determinar (236) uma faixa de bytes de um arquivo de uma representação de conteúdo de multimídia para solicitar a partir de um dispositivo de origem; caracterizado pelo fato de que compreende adicionalmente: formar (242) um localizador de recursos uniformes, URL, que especifica, na parte de percurso de arquivo do URL, de acordo com um gabarito, o arquivo e a faixa de bytes de acordo com as solicitações do dispositivo de origem; e emitir (244) uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente receber um arquivo de manifesto para o conteúdo de multimídia, em que o arquivo de manifesto especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, em que determinar a faixa de bytes compreende selecionar a faixa de bytes da representação a partir da pluralidade de faixas de bytes.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente receber dados da representação que compreendem uma estrutura de dados de índices de segmento, em que a estrutura de dados de índices de segmento especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que determinar a faixa de bytes compreende selecionar a faixa de bytes da representação a partir da pluralidade de faixas de bytes; em que a solicitação de OBTENÇÃO não inclui um cabeçalho “Faixa:”; e compreendendo adicionalmente formar a solicitação de OBTENÇÃO para incluir um cabeçalho de extensão que indica uma localização da faixa de bytes na parte de percurso de arquivo do URL da solicitação de OBTENÇÃO; receber um ou mais critérios de seleção para selecionar uma dentre uma pluralidade de redes de distribuição de conteúdo, CDNs; e selecionar uma CDN dentre a pluralidade de CDNs com base nos critérios de seleção, em que emitir a solicitação de OBTENÇÃO compreende emitir a solicitação de OBTENÇÃO para a CDN selecionada, e em que formar o URL de acordo com o gabarito compreende formar o URL de acordo com um gabarito de faixa de bytes específico da CDN selecionada.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: submeter uma mensagem de POST a um URL de redirecionamento para determinar uma dentre uma pluralidade de redes de distribuição de conteúdo, CDNs, a partir da qual recuperar os dados; e receber, em resposta à mensagem de POST, uma indicação de um URL base para uma dentre a pluralidade de CDNs, em que formar o URL compreende formar o URL para especificar o URL base recebido para a CDN dentre a pluralidade de CDNs, em que formar o URL de acordo com o gabarito compreende formar o URL de acordo com um gabarito de faixa de bytes específico da CDN selecionada, e em que emitir a solicitação de OBTENÇÃO compreende emitir a solicitação de OBTENÇÃO para uma dentre a pluralidade de CDNs.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que submeter a mensagem de POST compreende submeter uma ou mais mensagens de POST que indicam um ou mais dentre um URLBase, critérios de seleção e informações locais que incluem uma ou mais dentre informações de geolocalização, contagens de saltos e hora local do dia para o URL de redirecionamento.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente receber informações que indicam o gabarito a partir do dispositivo de origem; e em que determinar compreende determinar por um dispositivo cliente, em que formar compreende formar pelo dispositivo cliente e em que emitir compreende emitir pelo dispositivo cliente.

7. Dispositivo (40) para recuperar dados de multimídia, o dispositivo compreendendo: meios para determinar (52) uma faixa de bytes de um arquivo de uma representação de conteúdo de multimídia a ser solicitado a partir de um dispositivo de origem; caracterizado pelo fato de que compreende adicionalmente: meios para formar (52) um localizador de recursos uniformes, URL, que especifica, em uma parte de percurso de arquivo do URL, de acordo com um gabarito, o arquivo e a faixa de bytes de acordo com solicitações do dispositivo de origem; e meios para emitir (52) uma solicitação de OBTENÇÃO que especifica o URL formado para o dispositivo de origem.

8. Dispositivo, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente meios para receber um arquivo de manifesto para o conteúdo de multimídia, em que o arquivo de manifesto especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, em que os meios para determinar a faixa de bytes compreendem meios para selecionar a faixa de bytes da representação a partir da pluralidade de faixas de bytes; e meios para receber dados da representação que compreendem uma estrutura de dados de índices de segmento, em que a estrutura de dados de índices de segmento especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que os meios para determinar a faixa de bytes compreendem meios para selecionar a faixa de bytes da representação a partir da pluralidade de faixas de bytes; em que a solicitação de OBTENÇÃO não inclui um cabeçalho “Faixa:”; e compreendendo adicionalmente meios para formar a solicitação de OBTENÇÃO para incluir um cabeçalho de extensão que indica uma localização da faixa de bytes no URL da solicitação de OBTENÇÃO; meios para receber um ou mais critérios de seleção para selecionar uma dentre uma pluralidade de redes de distribuição de conteúdo, CDNs; e meios para selecionar uma CDN dentre a pluralidade de CDNs com base nos critérios de seleção, em que os meios para emitir a solicitação de OBTENÇÃO compreendem meios para emitir a solicitação de OBTENÇÃO para a CDN selecionada, e em que os meios para formar o URL de acordo com o gabarito compreendem meios para formar o URL de acordo com um gabarito de faixa de bytes específico para a CDN selecionada.

9. Método para enviar informações para dados de multimídia, o método caracterizado pelo fato de que compreende: prover (200) um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes, URL, e um gabarito de faixa de bytes em que o gabarito especifica, em uma parte de percurso de arquivo do URL, o arquivo e faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL para incluir uma solicitação de faixa de bytes dentro do URL; receber uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que a parte de percurso de arquivo do URL da solicitação especifica uma faixa de bytes de uma representação do conteúdo de multimídia; e emitir (216) dados de multimídia da representação que correspondem à faixa de bytes da solicitação, em resposta à solicitação.

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que o arquivo de manifesto compreende adicionalmente informações que especificam uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que a faixa de bytes especificada pela parte de percurso de arquivo do URL da solicitação compreende uma dentre a pluralidade de faixas de bytes; e compreendendo adicionalmente prover uma estrutura de dados de índices de segmento que especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que a faixa de bytes especificada pela parte de percurso de arquivo do URL da solicitação compreende uma dentre a pluralidade de faixas de bytes.

11. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que compreende adicionalmente receber um cabeçalho de extensão dentro da solicitação, em que o cabeçalho de extensão indica uma localização da faixa de bytes na parte de percurso de arquivo do URL da solicitação de OBTENÇÃO; e em que prover compreende prover por um dispositivo servidor, em que receber compreende receber pelo dispositivo servidor e em que emitir compreende emitir pelo dispositivo servidor; e em que prover compreende prover por um dispositivo de cache proxy, em que receber compreende receber pelo dispositivo de cache proxy e em que emitir compreende emitir pelo dispositivo de cache proxy; e em que a solicitação compreende uma primeira solicitação para a faixa de bytes da representação do conteúdo de multimídia, o método compreendendo adicionalmente: solicitar a faixa de bytes da representação a partir de um dispositivo servidor; armazenar dados em cache para a faixa de bytes recebida do dispositivo servidor; receber uma segunda solicitação diferente da faixa de bytes da representação; e emitir, em resposta à segunda solicitação, os dados armazenados em cache para a faixa de bytes da representação.

12. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que a solicitação compreende uma primeira solicitação e em que a faixa de bytes compreende uma primeira faixa de bytes, o método compreendendo adicionalmente: solicitar a primeira faixa de bytes da representação a partir de um dispositivo servidor; armazenar dados em cache para a primeira faixa de bytes, recebidos do dispositivo servidor; receber uma segunda solicitação que inclui um segundo URL construído de acordo com o gabarito de URL e o gabarito de faixa de bytes, em que o segundo URL da segunda solicitação inclui uma parte de percurso de arquivo que especifica uma segunda faixa de bytes da representação do conteúdo de multimídia, em que a segunda faixa de bytes se segue à primeira faixa de bytes; solicitar a segunda faixa de bytes da representação a partir do dispositivo servidor; e montar uma cópia local da representação utilizando os dados armazenados em cache para a primeira faixa de bytes e dados para a segunda faixa de bytes recebidos do dispositivo servidor; e em que o arquivo de manifesto indica que o gabarito de faixa de bytes se aplica globalmente a todas as redes de distribuição de conteúdo; e em que o gabarito de faixa de bytes compreende um dentre uma pluralidade de gabaritos de faixa de bytes, e em que o arquivo de manifesto indica que cada um dos gabaritos de faixa de bytes se aplica a uma respectiva rede dentre uma pluralidade de redes de distribuição de conteúdo.

13. Dispositivo (60) para enviar informações para dados de multimídia, o dispositivo caracterizado pelo fato de que compreende: meios para prover (62) um arquivo de manifesto para conteúdo de multimídia, em que o arquivo de manifesto especifica um gabarito de localizador de recursos uniformes, URL, e um gabarito de faixa de bytes em que o gabarito especifica, em uma parte de percurso de arquivo do URL, o arquivo e faixa de bytes, em que o gabarito de URL e o gabarito de faixa de bytes provêm um gabarito para formar um URL para incluir uma solicitação de faixa de bytes dentro do URL; meios para receber (72) uma solicitação que inclui um URL construído de acordo com o gabarito de URL e com o gabarito de faixa de bytes, em que uma parte de percurso de arquivo do URL da solicitação especifica uma faixa de bytes de uma representação do conteúdo de multimídia; e meios para emitir, em resposta à solicitação, dados de multimídia da representação que correspondem à faixa de bytes da solicitação.

14. Dispositivo, de acordo com a reivindicação 13, caracterizado pelo fato de que o arquivo de manifesto compreende adicionalmente informações que especificam uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que a faixa de bytes especificada pela parte de percurso de arquivo do URL da solicitação compreende uma dentre a pluralidade de faixas de bytes; e compreendendo adicionalmente meios para prover uma estrutura de dados de índices de segmento que especifica uma pluralidade de faixas de bytes que podem ser solicitadas para a representação, e em que a faixa de bytes especificada pela parte de percurso de arquivo do URL da solicitação compreende uma dentre a pluralidade de faixas de bytes; e meios para receber um cabeçalho de extensão dentro da solicitação, em que o cabeçalho de extensão indica uma localização da faixa de bytes na parte de percurso de arquivo do URL da solicitação de OBTENÇÃO; e em que a solicitação compreende uma primeira solicitação para a faixa de bytes da representação do conteúdo de multimídia, compreendendo adicionalmente: meios para solicitar a faixa de bytes da representação a partir de um dispositivo servidor; meios para armazenar dados em cache para a faixa de bytes, recebidos do dispositivo servidor; meios para receber uma segunda solicitação diferente da faixa de bytes da representação; e meios para emitir, em resposta à segunda solicitação, os dados armazenados em cache para a faixa de bytes da representação.

15. Memória legível por computador caracterizada pelo fato de que contém gravado na mesma o método conforme definido em qualquer uma das reivindicações 1 a 6 ou 9 a 12.