BRPI1013145B1

BRPI1013145B1 - métodos e dispositivos para transmissão de conteúdo de mídia via protocolo de transferência de hipertexto

Info

Publication number: BRPI1013145B1
Application number: BRPI1013145-0A
Authority: BR
Inventors: David Furbeck
Original assignee: Blackberry Limited
Priority date: 2009-06-15
Filing date: 2010-06-14
Publication date: 2021-01-12
Also published as: MX2011013770A; CN102461119A; BRPI1013145A8; KR20130045945A; CA2765532C; US8244901B2; SG176796A1; CN102461119B; US20120017004A1; US20100318600A1; BRPI1013145A2; JP5642779B2; EP2443807B1; KR101364299B1; WO2010147878A1; EP2443807A1; KR20120035187A; JP2012533913A; CA2765532A1; AU2010260303A1

Abstract

MÉTODOS R APARELHO FACILITAR ADAPTAÇÃO SEM SESSÃO CONTROLADA PELO CLIENTE. O método exemplo revelado para gerenciar conteúdo de mídia inclui acessar informação de metadados para uma mídia disponível e recuperar, do metadados acessados, pelo menos um localizador de recurso uniforme (URL) e um ou mais alcances byte (byte range), em que uma ou mais parcelas de mídia disponível sendo endereçável pela combinação de um ou mais alcances de byte e a URL. O método exemplo também inclui enviar uma primeira solicitação solicitando uma primeira pelo menos uma parcela da mídia disponível com base no metadado recuperado.

Description

APLICAÇÕES RELACIONADAS

Esta Patente reivindica o benefício do Pedido Provisório de Patente dos E. U. A de número 61/187.090 requerido em 15 de junho de 2009, e Pedido de Patente dos Estados Unidos de número 12/814.566 requerido em 14 de junho de 2010, que são aqui incorporados por referência em suas inteirezas.

CAMPO DA REVELAÇÃO

A presente revelação relaciona-se genericamente à entrega de mídia sem fio e, mais particularmente, a métodos e aparelho para facilitar a adaptação sem sessão controlada pelo cliente.

HISTÓRICO

Equipamento do usuário (UE) poderá receber e exibir conteúdo de mídia para o usuário em resposta a uma solicitação. Quando uma ou mais solicitações de mídia forem solicitadas pelo UE, o conteúdo de mídia poderá ser fluido para o UE por meio de um número de protocolos, como o Real Time Streaming Protocol (RTSP - Protocolo Streaming em Tempo Real).

Para fornecer ao UE conteúdo de mídia streaming, o UE envia um ou mais comandos para um servidor de mídia, e o servidor de mídia responde com uma descrição, como por meio do Session Description Protocol (SDP - Protocolo de Descrição de Sessão). Quando o conteúdo de mídia é streamed para o UE, o servidor de mídia tipicamente mantém uma sessão ativa no todo. BREVE DESCRIÇÃO DOS DESENHOS As Figuras 1, 2A e 2B ilustram o fluxo de mensagem exemplar entre o equipamento do usuário (UE) e um servidor para facilitar a adaptação sem sessão controlada pelo cliente. As Figuras 3 e 4 ilustram caixas objetos de arquivo 3GPP exemplares que poderão ser implementadas para facilitar a adaptação sem sessão controlada pelo cliente. As Figuras 5 e 6 ilustram um servidor exemplar que pode ser implementado de acordo com esta revelação. A Figura 7 ilustra um EU exemplar que pode ser implementado de acordo com esta revelação. As Figuras 8 e 9 ilustram fluxogramas de processos exemplares para facilitar a adaptação sem sessão controlada pelo cliente.

DESCRIÇÃO DETALHADA

Embora o que segue revele métodos e aparelho exemplares incluindo, entre outros componentes, software executada em hardware, deve ser observado que esses métodos e aparelho são meramente ilustrativos e não devem ser considerados como limitativos. Por exemplo, é contemplado que qualquer um ou todos esses componentes de hardware e de software poderiam ser incorporados exclusivamente em hardware, exclusivamente em software, exclusivamente em firmware, ou em qualquer combinação de hardware, de software e/ou de firmware. Assim, embora o que segue descreva métodos e aparelho exemplares, pessoas tendo habilidade ordinária na tecnologia prontamente apreciarão que os exemplos fornecidos não são a única maneira de implementar esses métodos e aparelho.

Os métodos e aparelho exemplares aqui descritos podem ser utilizados pelo equipamento do usuário (UE) para controlar o tipo de parâmetros de mídia renderizados no UE com base em uma ou mais condições de canal e/ou condições de corrente do UE. O UE poderá renderizar qualquer tipo de mídia incluindo, mas sem a elas se limitar, áudio (por exemplo, áudio MP3) e/ou vídeo, e parâmetros de mídia poderão incluir, mas sem a elas se limitar, uma velocidade de bit de mídia, resolução da mídia, etc. Embora os provedores de conteúdo de mídia codifiquem o conteúdo de mídia em uma ou mais configurações diferentes (aqui referidas como "configurações de mídia codificadas"), cada uma tendo uma ou mais velocidade de bit, resolução, dimensão, etc., diferentes, os dispositivos em que o conteúdo de mídia é renderizado não participa na seleção de qual configuração de mídia codificada é mais apropriado com base nas condições atuais. Como é aqui utilizado, o termo adaptação relaciona-se à circunstância em que o conteúdo de mídia é modificado e/ou selecionado para ser entregue em formato mais bem adequado pelas atuais condições de canal e/ou capacidades do UE. Do ponto de vista do usuário, condições de canal adversas e/ou limitações do UE (por exemplo, a capacidade do UE renderizar mídia a certa velocidade de bit, resolução, a limitação de velocidade do processador UE, etc.) poderá se manifestar como áudio/vídeo saltitante (A/V), pausas relativamente longas e/ou tempos de utilização da memória provisória e/ou A/V que não está em sincronia. O UE aqui referido poderá incluir, mas não é a eles limitado, dispositivos de comunicação móvel, dispositivos de computação móvel, ou qualquer outro dispositivo capaz de comunicar de maneira sem fio com uma rede sem fio. Esses dispositivos, também referidos como terminais ou terminais sem fio poderão incluir telefones inteligentes móveis (por exemplo, um telefone inteligente BLACKBERRY®), assistentes digitais pessoais sem fio (PDA), computadores laptop/notebook/netbook com adaptadores sem fio, etc.

Os métodos e aparelho exemplares são aqui descritos em conexão com a norma de comunicação de rede de área local sem fio (WLAN) conhecido como IEEE (Institute for Electrical and Electronics Engineers( 802.11, que, entre outras coisas, define o inter-trabalho com redes externas. No entanto, os métodos e aparelho exemplares poderão adicionalmente ou alternativamente ser implementados em conexão com outras normas de comunicação sem fio, incluindo outras normas WLAN, normas de rede de área pessoal (PAN), normas de rede de área ampla (WAN) , ou normas de comunicação celular.

A experiência do usuário associada a técnicas conhecidas ou normas para fluir o conteúdo de mídia de um servidor para um UE inclui várias limitações. Por exemplo, o fluir tradicional de conteúdo de mídia emprega o Real Time Streaming Protocol (RTSP), que é um protocolo cliente/servidor que permite o fluir em tempo real e/ou quase tempo real. Geralmente, na operação de solicitar mídia de um servidor, o UE envia um comando DESCRIBE a um servidor de mídia, e o servidor de mídia responde com uma descrição de apresentação (por exemplo, SDP (Session Description Protocol - Protocolo de Descrição de Sessão)). A informação SDP inclui a descrição da apresentação de mídia geral e/ou cada fluxo que é utilizado para compor a apresentação. O cliente poderá então receber a mídia desejada através de pacotes do protocolo de Internet (IP), do protocolo de datagrama do usuário (UDP) , ou do RTP (Protocolo em Tempo Real). No entanto, nesta situação, controle adicional ainda é necessário antes da mídia começar a fluir para o UE ou exibir no UE, como o comando SETUP emitido pelo cliente, o comando PLAY, e um comando TEARDOWN quando o cliente tiver terminado com a mídia.

Embora as técnicas streaming RTSP tradicionais evitem a necessidade de uma conexão de protocolo de controle de transmissão (TCP) entre o cliente e o servidor de mídia, o servidor de mídia precisa ser capaz de manter uma sessão ativa para cada um e todo cliente que solicite mídia. Adicionalmente, o streaming RTSP envia pacotes para o cliente a uma velocidade média ou a uma velocidade em que a mídia foi codificada, e embora a transmissão de pacote de velocidade possa ser afogado com base no estado de enchimento da memória provisória, o streaming tradicional e/ou streaming comutado por pacote (PSS) ainda exibe questões relacionadas a atravessar paredes de fogo, tradução de endereço de rede (NAT) e exigem servidores streaming relativamente caros. Os servidores de Web normais, diferentemente dos servidores de streaming da mídia, tipicamente custam significativamente menos do que os servidores de streaming de mídia e empregam Hypertext Transfer Protocol (HTTP) (por exemplo, HTTP 1.1) sem a potência de processamento adicional e/ou complexidade associado ao estabelecimento, manutenção, e/ou derrubada dos protocolos de comunicação com base no estado (por exemplo, RTSP). Como tal, servidores de streaming de mídia tipicamente sofrem de uma incapacidade de escalonar bem, devido, em parte, aos requisitos de processamento significativos à medida que a demanda cresce. Os servidores de Web padrão, por outro lado, são ocasionalmente referidos como servidores "burros" que retornam o conteúdo que é solicitado pelo cliente, o que minimiza a complexidade, o custo, e escalona mais bem do que os servidores de streaming de mídia mais caros. A Figura 1 ilustra um intercâmbio de mensagem exemplar 100 entre o equipamento do usuário (UE) 102 e o servidor 104 associado ao fluxo de mídia pré-gravado (isto é, não ao vivo). Conforme descrito em maior detalhe abaixo, o servidor exemplo 104 poderá ser um servidor de Web padrão ou um servidor HPPT similar. Em um exemplo, o sistema poderá empregar um ou mais servidores streaming de mídia (não mostrados) para facilitar o streaming de mídia para um dispositivo sem fio, os métodos e aparelho aqui descritos permitem que servidores de custo ponderado sejam utilizados em vez dos servidores streaming de mídia relativamente caros. Para iniciar o recebimento da mídia, o UE exemplar 102 gera uma solicitação sem sessão para o servidor exemplar 104 (106) . A solicitação sem sessão (106) poderá incluir uma solicitação HTTP que identifica um arquivo do projeto de parceria de terceira geração (3GPP) identificado por um localizador de recurso uniforme (URL) associado a uma seleção feita pelo usuário do UE exemplar 102. Adicional ou alternativamente, a solicitação sem sessão exemplar poderá incluir uma faixa de byte do arquivo para baixar, como por meio de um comando GET suportado no HTTP 1.1. Em resposta ao receber a solicitação sem sessão (106), o servidor exemplar 104 fornece o arquivo 3GPP identificado correspondente, que inclui uma série de objetos referidos como caixas. Cada caixa no arquivo 3GPP poderá conter informação de mídia ou metadados, como a mídia (por exemplo, áudio, vídeo, etc.) construída com características de mídia predeterminadas (por exemplo, uma resolução predeterminada, uma velocidade de bits predeterminada, um codec predeterminado, e/ou qualquer combinação destes). O servidor exemplar 104 transmite o arquivo 3GPP para o UE 102 (108) para permitir que a mídia nele contida seja renderizada pelo UE 102. Adicionalmente, o UE exemplar 102 analisa o arquivo 3GPP recebido por caixas objeto para identificar uma ou mais permutações alternativas das características da mídia estão disponíveis no servidor 104. Diferentemente do streaming tradicional, em que o servidor controla a adaptação e/ou a velocidade em que os pacotes são enviados para o UE (por exemplo, tipicamente uma velocidade em tempo real equivalente à velocidade em que a mídia foi codificada) , os métodos e aparelho aqui descritos permitem ao UE controlar as características da mídia associadas ao fluxo de uma maneira que emprega servidores tradicionais da Web em vez de um ou mais servidores streaming de mídia que são relativamente onerosos. Como resultado, o UE 102 poderá controlar uma o mais decisões relacionadas à taxa de bit em stream da mídia, a resolução, etc., com base, por exemplo, em uma ou mais condições atuais do UE 102 (por exemplo, congestionamento de canal, degradação da potência do sinal, etc.) e/ou uma ou mais capacidades do UE 102 (por exemplo, enchimento da memória provisória, capacidades; velocidade do processador do UE, etc.). Adicionalmente, o streaming tradicional tipicamente emprega o RTSP, que requer recursos de processamento tanto do UE como do servidor para manter uma ou mais sessões. Esses recursos de processamento são particularmente onerosos nos servidores de mídia que precisam manter a sessão para cada instância de streaming atual, mesmo se o UE não estiver efetuando uma ou mais funções de controle (por exemplo, reproduzir, parar, para frente, inverter, saltar, etc.). Por outro lado, os métodos e aparelho aqui descritos empregam streaming HTTP, que elimina quaisquer requisitos de manutenção de sessão, assim reduzindo a complexidade e/ou custo do servidor.

Após o UE exemplar 102 receber o arquivo 3GPP (108) e analisar o arquivo 3GPP recebido quanto a metadados da URL indicativo de características de mídia alternativa disponível, o UE 102 navega até a URL analisada para solicitar qualquer metadado adicional ali contido (110). O metadado adicional retornado do servidor exemplar 104 (112) poderá incluir, mas não é a ele limitado, características de mídia adicional/alternativa para o conteúdo de mídia, informação indicativa de se a mídia é ao vivo, valor índice fragmento, e/ou valores recuados de byte para permitir buscar. Como é descrito em maior detalha abaixo, com o metadado adicional, o UE exemplar 102 poderá solicitar um dos fluxos de mídia alternativos tendo as características da mídia alternativa (por exemplo, uma velocidade de bit mais baixa, uma resolução mais baixa, um codec alternativo, etc.) (114). Por exemplo, o UE 102 poderá solicitar um fluxo de mídia alternativo com base nas condições de canal degradadas, enchimento da memória provisória, e/ou limitações do UE para renderizar mídia a velocidades de bit relativamente altas, resoluções, etc. O servidor exemplar 104 responde à solicitação ao enviar o conteúdo de mídia selecionado (116). A Figura 2A ilustra um intercâmbio de mensagem exemplar 200 entre o UER 102 e o servidor 104 para uma situação em que o conteúdo de mídia fornecido através do servidor 104 é ao vivo e não pré-gravado. Durante uma tentativa pelo UE 102 de receber um arquivo 3GPP ao vivo (por exemplo, uma série de fragmentos de arquivo 3GPP relacionados armazenados no servidor 104 pelo criador do conteúdo de mídia ou distribuidor (por exemplo, o televisionador)), um cliente utilizando o UE 102 poderá preferir buscar diretamente o fragmento ao vivo (por exemplo, mais recente) em vez de iniciar em um período no tempo anterior de visualização. Por exemplo, algumas solicitações de streaming ao vivo poderão iniciar do UE 102 após o evento ao vivo haver ocorrido por um período de tempo relativamente longo (por exemplo, vários minutos, horas, etc.), e o cliente poderá tentar buscar através do UE 102 o arquivo 3GPP disponível mais recente da série. Embora as técnicas de streaming tradicionais sejam analisadas em um esforço para identificar a mídia disponível mais recente, essas técnicas são intensivas de processo e consumidoras de tempo. Os métodos e aparelho aqui descritos permitem a busca eficiente de conteúdo streaming ao vivo ao manter e/ou de outra forma receber um meta-arquivo streaming ao vivo que é atualizado em base contínua, periódica, aperiódica, e/ou cronogramada. Como tal, um ou mais locais de busca específicos dos fragmentos de arquivo 3GPP poderão ser identificados após o UE exemplar 102 acessar o meta-arquivo streaming ao vivo atualizado para localizar um valor de índice do fragmento de arquivo atual e/ou um valor de recuo de byte.

No exemplo ilustrado da Figura 2A, o UE 102 gera uma solicitação HTTP sem sessão para o servidor exemplar 104 (202) e recebe caixas objeto tendo metadados e informação de mídia (204). Como é descrito em maior detalhe abaixo, as caixas objeto recebidas poderão incluir, mas sem a elas estar limitadas, informação indicativa de se a mídia é ao vivo, a URL para referenciar metadados adicionais (por exemplo, para minimizar o tamanho da carga de metadados 3GPP), uma lista da mídia alternativa tendo características de mídia alternativas, uma lista dos locais do arquivo 3GPP disponíveis associados às características de mídia alternativas (por exemplo, URLs), e/ou informação SDP. O UE exemplar 102 consulta a URL recebida (206 e recebe metadados adicionais, se houver algum (208). No evento de que os metadados recebidos do servidor (202) esteja completo e/ouse metadados adicionais e/ou URLs não forem fornecidas, os intercâmbios 206 e/ou 208 poderão ser eliminados.

Para permitir ao UE 102 buscar diretamente a um local desejado de mídia, o UE 102 seleciona um valor índice de fragmento e/ou um valor de recuo de byte do meta-arquivo de streaming ao vivo fornecido pelo servidor 104 (210). Ao continuar a mídia ao vivo, a parte que fornece o conteúdo de mídia (por exemplo, o televisionador) atualiza o meta=arquivo em streaming ao vivo no local especificado pela URL recebida (206) , que poderá ser armazenado no servidor 104 e/ou qualquer outro local (por exemplo, outro servidor, um recurso de armazenamento na rede, um recurso de Internet, etc.) . No evento de que o cliente do UE 102 deseja buscar um local de índice de fragmento 3GPP alternativo e/ou reconfirmar onde o índice de fragmento mais recente está localizado, o UE 102 poderá determinar se o metadado recuperado anteriormente acredita-se que seja atual. Por exemplo, no evento de que o metadado recuperado anteriormente seja de vários minutos de idade, durante o qual valores de índice do fragmento atualizado e/ou valores de recuo de byte poderão estar disponíveis, o UE 102 poderá consultar o URL novamente (212) e aguardar uma resposta, por exemplo, do servidor 104 contendo um meta-arquivo em streaming ao vivo atualizado (214), que contém valores de índice de fragmento atualizado e/ou valores de recuo de dados atualizado. 0 UE 102 poderá consultar o URL em base periódica, aperiódica, cronogramada, e/ou manual para manter consciente dos detalhes do arquivo 3GPP atual associado ao conteúdo de mídia ao vivo. A Figura 2B ilustra um intercâmbio de mensagem exemplar 250 entre o UE 102 e o servidor 104 que permite ao UE 102 controlar a adaptação em resposta às preferências do usuário e/ou as condições de canal em mudança. No exemplo ilustrado na Figura 2B, o intercâmbio 250 começa após o servidor 104 haver transmitido uma primeira instância de metadados e/ou mídia, como a transmissão mostrada pelo intercâmbio 204. Em resposta a condições de canal modificadas 252 pelo UE exemplar 102, o UE 102 consulta o URL (por exemplo, o URL fornecido no intercâmbio 212 da Figura 2A) para identificar se mídia alternativa tendo características de mídia alternativas estão disponíveis (254) . Por outro lado, o UE exemplar 102 poderá já ter o metadado indicativo de velocidades de bit disponíveis, resoluções etc., em virtude da solicitação sem sessão anterior 202. O servidor exemplar 104 responde com metadados indicativos do local do arquivo 3GPP e características de mídia correspondente disponível para o UE 102 (256). Com base nas características de mídia disponíveis, o UE exemplar 102 seleciona um arquivo 3GPP que encara as condições de canal modificadas 252. As condições de canal modificadas poderão incluir, mas não estão a elas limitadas, largura de banda de canal diminuída (por exemplo, devido ao abarrotamento do canal), condições de queda aumentadas, interferência co-canal, esmaecimento, valores de latência aumentados, e/ou jitter aumentado. Adicional ou alternativamente, o desempenho degradado poderá ser devido a uma ou mais limitações do UE 102, como a capacidade do UE 102 processar/renderizar média a certa velocidade de bit e/ou resolução. Essa degradação nas condições de canal e/ou desempenho do UE 102 poderá ser verificada por um ou mais limites no UE 102 que, quando superado (por exemplo, superar um limite inferior de desempenho, superar um limite superior de desempenho) permite ao UE 102 solicitar um arquivo 3GPP que é menos suscetível a condições de canal ruins. Em outras palavras, arquivos 3GPP com velocidade de bit mais baixa, arquivos 3GPP com resolução mais baixa, e/ou arquivos 3GPP tendo codecs alternativos poderão resultar em uma experiência de cliente melhor no UE 102 quando a largura de banda estiver limitada devido a conduções de canal ruins. O UE exemplar 102 seleciona o arquivo 3GPP alternativo (258), como o arquivo 3GPP tendo uma velocidade de bit mais baixa, e o servidor exemplar 104 responde ao fazer streaming do arquivo 3GPP selecionado através do HTPP (por exemplo, uma resposta do servidor a um comando HTTP GET do cliente) (260) .

Por outro lado, no evento de as condições de canal melhorarem, o UE exemplar poderá emitir outra solicitação ao servidor 104 para um arquivo 3GPP que pode ser acomodado pelas condições de canal melhoradas. Em outras palavras, o UE 102 poderá solicitar uma resolução relativamente alta e/ou velocidade de bit alta no arquivo 3GPP quando as condições de canal mantiverem largura de banda suficiente por uma quantidade de tempo dada. Como foi descrito acima, o UE 102 poderá monitorar as condições de canal em base periódica, aperiódica, cronogramada, e/ou manual para coletar medições de canal (por exemplo, jitter de canal, latência de canal, etc.) e comparar essas medições a um ou mais limites. Se essas condições de canal superarem um ou mais limites de maneira favorável (por exemplo, valores de velocidade de bit medidas superam o valor limite de velocidade de bit mínima para vídeo sem fio de alta resolução) , o UE 102 poderá solicitar um ou mais arquivos 3GPP (por exemplo, arquivos 3GPP tendo uma resolução mais alta, velocidade de bit mais alta, etc.) que opere favoravelmente sob essas condições modificadas. A Figura 3 ilustra uma parcela exemplar de caixas objeto de arquivo 3GPP 300 implementadas de acordo com esta revelação. Geralmente, o formato de arquivo 3GPP se enquadra nos requisitos estabelecidos na 3GPP TS 26.244, que tem por base a ISSO/IEC 14496-12 ISO Base Media File Format (referido como a especificação de arquivo MP4) . Arquivos 3GPP estão dispostos como uma série de objetos hierárquicos denominados caixas, cada uma das quais contém media ou metadados. Cada caixa tem um tipo de caixa associado, que é tipicamente um nome de quatro caracteres e um tamanho associado (por exemplo, uma integral não assinada de 32 bits). Embora alguns tipos de caixa sejam obrigatórias e encontradas dentro de cada arquivo 3GPP, a especificação MP4 inclui um número de tipos de caixa opcionais. A hierarquia de tipo de caixas identifica uma caixa de nível superior em uma coluna mais à esquerda, como a coluna mais à esquerda 302 da Figura 3. Um tipo de caixa "ftyp" (tipo de arquivo) 304 normalmente ocorre primeiro em um arquivo 3GPP dado. Uma caixa "moov" (caixa de cinema) 306 armazena metadados para uma apresentação e ocorre ao nível superior (mais à esquerda) de um arquivo 3GPP. A caixa "meta" (308) contém metadados descritivos e/ou anotativos para o arquivo 3GPP, que poderá incluir, mas não está limitado aos codecs disponíveis 310, velocidades de bit disponíveis 312, resoluções disponíveis 314, outros locais de arquivos 316, e/ou um URL ao qual metadados adicionais poderão estar localizados 318.

No exemplo ilustrado da Figura 3, a caixa "meta" exemplar 308 está incluída sob o nível mais alto da caixa "moov" 306 para permitir a baixa cedo e/ou análise pelo UE exemplar 102 após o arquivo 3GPP correspondente ser transmitido pelo servidor 104. Geralmente, ao o servidor 104 transmitir o arquivo 3GPP para o UE 102, o UE 102 poderá imediatamente começar a analisar o arquivo 3GPP ao ele chegar. No evento de o UE 102 necessitar imediatamente de uma ou mais mídia alternativa tendo, por exemplo, uma resolução mais baixa, o UE 102 poderá fazer outra solicitação para o servidor exemplar 104 sem esperar pela parcela restante do arquivo 3GPP para baixar. Em outras palavras, o UE 102 poderá ser mais reativo às condições de canal conhecidas ao descontinuar a baixa do conteúdo da mídia atual em favor de conteúdo de mídia alternativo que provavelmente irá desempenhar melhor com base nas condições de canal atuais e/ou capacidades do UE 102. Por outro lado, a caixa exemplar "meta" 308 poderá estar localizada, em vez disso, na coluna mais à esquerda 3 02 e ao nível de linha inferior em um esforço para permitir que o conteúdo streamed apareça no UE exemplar 102 tão logo seja possível.

A adaptação poderá incluir um ou mais arquivos estruturados como uma caixa "moov" com ou sem uma caixa "meta". Adicionalmente, o arquivo 3GPP exemplar poderá incluir um ou mais fragmentos que são alinhados no tempo em que cada fragmento começa com um ponto de acesso aleatório. Como tal, a troca entre arquivos poderá ser efetuada. A identificação de arquivo poderá ainda ser facilitada através de um ou mais identificadores de marca, assim fornecendo ao cliente uma indicação que o enlace metadado para outros arquivos é possível.

No exemplo ilustrado da Figura 4, uma parcela exemplar de caixas objeto do arquivo 3GPP 40 0 inclui uma caixa "hnti" (dica) 402. A caixa "hnti" 402 é a extensão de um tipo de caixa de dados do usuário "udta" 4 04 e inclui informação SDP. Embora a informação SDP seja tipicamente associada à comunicação com base em sessão em vez da comunicação HTTP, um ou mais parâmetros SDP poderão ser embutidos dentro da caixa "hnti" 402 para orientar o UE exemplar 102 ao URL contendo metadados adicionais. Por exemplo, SDP inclui um número de campos, incluindo um campo "u=" 406 associado a um URL. O servidor exemplar 104 poderá apensar um URL ao campo "u=" 4 06 e ainda embutir o campo "u=" na caixa "hnti" 402 para permitir ao UE localizar metadados adicionais quando do recebimento. A Figura 5 é um servidor exemplar 104 que pode ser implementado de acordo com esta revelação. O servidor exemplar 104 da Figura 5 inclui um processador 502 para efetuar as operações gerais do servidor 104, uma memória flash 504, memória de acesso aleatório 506, e uma biblioteca de mídia 508, todas as quais são acopladas ao processador 502. Como foi descrito acima, o servidor exemplar 104 poderá ser um servidor da Web padrão como é conhecido pelas pessoas tendo habilidade ordinária na tecnologia. Para comunicar com o UE 102, o servidor exemplar 104 inclui um subsistema de comunicação 510 para facilitar a comunicação em rede (por exemplo, comunicação de rede de área local sem fio através do IEEE® (Institute for Electrical and Electronics Engineers) 802.11 e/ou a comunicação sem fio no Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Networks (UTRANs)). O subsistema de comunicação exemplar 510 poderá ser substancialmente similar ao subsistema de comunicação exemplar 711 descrito abaixo em conexão com a Figura 7. O servidor exemplar 104 da Figura 5 poderá estar comunicativamente conectado a um gerenciador de arquivo de mídia opcional 512 para gerar e/ou de outra forma gerenciar conteúdo de caixa objeto dos arquivos 3GPP enviados do servidor 104 para um ou mais UEs, como o UE exemplar 102 das Figuras 1, 2A, e 2B. Em operação, o subsistema de comunicação exemplar 510 recebe uma conexão HTTP do UE 102 com uma solicitação de mídia, como o comando GET do HTTP padrão. Solicitações de mídia poderão incluir URLs digitadas e/ou de outra forma selecionadas pelo usuário do UE 102 que dirigem uma transmissão TCP para o servidor 104. O servidor exemplar 104 recupera um arquivo de mídia 3GPP associado à solicitação, por exemplo, de um ou mais bibliotecas de mídia 508, que poderão ser implementadas como uma ou mais bases de dados interna e/ou externa ao servidor 104. Em alguns exemplos, a parte que fornece a mídia constrói arquivos 3GPP para se enquadrar a um ou mais pedido de tipo de caixa e/ou configurações. Em outros exemplos, o gerenciador de arquivo de mídia exemplar 512 constrói e/ou de outra forma modifica o arquivo 3GPP recuperado para se enquadrar com tipos de caixa e/ou a colocação hierárquica de tipo de caixa. Por exemplo, o gerenciador de arquivo de mídia 512 poderá incluir a caixa "meta" 3 08 como um dependente na caixa "moov" 3 06 de modo que um UE alvo 102 pode identificar conteúdo de mídia alternativa disponível tão logo seja possível após a recepção, como está mostrado na Figura 3. Por outro lado, o gerenciador de arquivo de mídia exemplar 512 poderá incluir a caixa "meta" 308 como uma caixa de primeiro nível sozinha. Quando do término da construção e/ou aumento do arquivo 3GPP selecionado, o subsistema de comunicação exemplar 510 transmite o arquivo 3GPP para o UE solicitante 102 através do HTTP. No entanto, os métodos e aparelho exemplares aqui descritos para facilitar a adaptação sem sessão controlada pelo cliente poderá ser empregado com um servidor da Web HTTP padrão de indústria.

O gerenciador de arquivo de mídia exemplar poderá construir e/ou aumentar o arquivo 3GPP selecionado para incluir informação SDP. Como foi descrito acima, o campo "u=" 406 poderá ser cheio com um URL para permitir que o UE recebedor 102 identifique o local para o qual metadados adicionais são armazenados. A utilização do campo "u=" exemplar 406 permite, por exemplo, a redução da carga de metadados para os arquivos 3GPP selecionados. Como resultado, o conteúdo de mídia recebido pelo UE 102 poderá renderizar mais cedo, pois há menos informação de carga de metadados para transferir do servidor 104 para o UE 102. A Figura 6 ilustra detalhe adicional do gerenciador de arquivo de mídia exemplar 512 da Figura 5. No exemplo ilustrado da Figura 6, o gerenciador de arquivo de mídia 512 inclui um gerenciador de caixa objeto 602, e um atualizador de metadados streaming ao vivo 604. Em operação, o gerenciador de caixa objeto exemplar 602 constrói, providencia, e/ou apensa caixas objeto ao arquivo 3GPP selecionado de uma maneira que permite que o UE 102 fique ciente de quais conteúdos estão disponíveis no servidor 104. Como tal, o UE 102 poderá participar na adaptação de mídia com base, por exemplo, nas preferências de transmissão e/ou condições de canal existentes, como a memória flash exemplar 504.

Perfis poderão incluir, mas não limitativos, de configurações de pedidos de caixa objeto que promove a renderização da mídia assim que seja possível após o recebimento pelo UE 102 ao minimizar a carga de metadados de qualquer arquivo 3GPP selecionado. Essa minimização da carga poderá ser efetuada pelo gerenciador de caixa objeto 602 incluindo uma referência de metadados URL na caixa "meta" 308 em vez de um ou mais tipos de valor de metadados discretos. Adicional ou alternativamente, o gerenciador de caixa objeto exemplar 602 poderá empregar a caixa "hnti" 402 ao utilizar o campo "u=" 406 para associar uma URL de referência de metadados. Por outro lado, o gerenciador de caixa objeto exemplar 602 poderá ordenar uma ou mais configurações de caixa objeto de maneira a promover conscientização cedo das opções de adaptação da mídia para o UE 102, por exemplo, ao incluir metadados cedo no arquivo 3GPP. Como tal, o UE 102 poderá analisar uma ou mais caixas (por exemplo, a caixa "meta" 308) logo após a caixa "ftyp" inicial 304 para aprender de arquivos de configuração de mídia codificada alternativa adequadas para as condições de canal atuais. Como tal, o UE exemplar 102 poderá imediatamente parar todas as tentativas de uma caixa de arquivo3GPP pendente em favor de um arquivo de mídia (por exemplo, de largura de banda menor) alternativo.

O atualizador de metadados streaming ao vivo exemplar 604 poderá operar em base periódica, aperiódica, cronogramada, e/ou manual para atualizar o meta-arquivo- fluxo-ao vivo (ver o intercâmbio 214 da Figura 2A). Como é descrito acima, mídia pré-gravada tipicamente inclui uma compilação relativamente severa dos metadados para descrever trilhas individuais e/ou pontos de busca dentro da mídia para permitir, por exemplo, operações de busca, reproduzir, rebobinar, ir para frente rápido, etc. No entanto, o conteúdo de mídia ao vivo tipicamente contém menos metadados associados para permitir tal controle. Como tal, o criador do conteúdo de mídia tipicamente só tem tempo suficiente e/ou potência de processamento para gerar valores índices de fragmento e/ou valores de recuo de dados antes de criar o um ou mais arquivos 3GPP que compreendem o conteúdo de mídia ao vivo. 0 atualizador de metadados streaming ao vivo exemplar 604 recupera os valores índices de fragmento e/ou os valores de recuo de dados assim que eles são tornados disponíveis e prepends esses valores para o meta-arquivo-fluxo-ao vivo. Enquanto o evento de mídia continua, o meta-arquivo-fluxo-ao vivo associado cresce em tamanho com os valores índice de fragmento mais recentes e valores de recuo de dados mais recentes gravados no início do arquivo. A Figura 7 é um UE exemplar que pode ser implementado de acordo com esta revelação. O UE 700 é preferivelmente um dispositivo de comunicação sem fio bilateral tendo pelo menos capacidades para comunicação de dados e de voz. O UE 700 tem preferivelmente a capacidade de se comunicar com outros sistemas de computador em uma rede, uma intranet, e/ou a Internet. Dependendo da funcionalidade exata fornecida, o dispositivo sem fio poderá ser referido como um dispositivo de mensagens de dados, um dispositivo de chamadas bilaterais, um dispositivo de correio eletrônico sem fio, um telefone celular com capacidade para mensagens de dados, um aparelho de Internet sem fio, ou um dispositivo de comunicação de dados, como exemplos.

Quando o UE 7 00 é ativado para a comunicação bilateral, ele irá incorporar um subsistema de comunicação 711, incluindo tanto o receptor 712 como o transmissor 714, bem como componentes associados como o um ou mais elementos de antena, preferivelmente embutidos ou internos, 716 e 718 (osciladores locais (LOs) 713, e um módulo de processamento como um processado de sinal digital (DSP) 720. O projeto particular do subsistema de comunicação 711 será dependente da rede de comunicação em que o dispositivo pretende operar. Por exemplo, o UE 700 poderá incluir um subsistema de comunicação 711 projetado para operar dentro da rede de serviço de rádio de pacote geral (GPRS) e/ou a rede UMTS.

Os requisitos de acesso à rede também irão variar dependendo do tipo de rede 719. Por exemplo, nas redes UMTS e GPRS, o acesso à rede é associado a um assinante ou usuário do UE 700. Por exemplo, o dispositivo móvel GPRS, portanto, requer um cartão de módulo de identidade de assinante (SIM) para operar na rede GPRS. No UMTS, um módulo de identidade de assinante universal (USIM) ou o módulo SIM é necessário. No entanto, no CDMA um cartão módulo de identidade de usuário removível (RUIM) é necessário. Eles serão referidos aqui como a interface UIM. Sem uma interface UIM válida, o dispositivo móvel poderá não ser integralmente funcional. Funções de comunicação não de rede ou local, bem como funções legalmente necessárias (se as houver) como chamadas de emergência, poderão estar disponível, mas o dispositivo móvel 700 será incapaz de realizar quaisquer outras funções envolvendo a comunicação por rede. A interface UIM 744 é normalmente similar à fenda de cartão dentro da qual um cartão pode ser inserido e ejetado como um disquete ou cartão PCMCIA. O cartão UIM pode ter aproximadamente 64K de memória e conter muitas configurações chaves 751, e outra informação 753 como identificação, e informação relacionada ao assinante.

Quando os procedimentos de registro ou ativação em rede necessários tiverem sido completados, o UE 700 poderá enviar e receber sinais de comunicação pela rede 719. Os sinais recebidos por uma antena 716 através da rede de comunicação 719 são entrados em um receptor 712, que poderá efetuar funções comuns de receptor como amplificação de sinal, conversão descendente da frequência, filtragem, seleção de canal e assemelhados, incluindo a conversão analógico para digital (A/D) . A conversão A/D de um sinal recebido permite que funções de comunicação mais complexas como a demodulação e decodificação sejam realizadas no DSP 720. De maneira similar, os sinais a serem transmitidos são processados, incluindo modulação e codificação, por exemplo, pelo DSP 720 e entrados no transmissor 714 para a conversão digital para analógico, conversão ascendente da frequência, filtragem, amplificação e transmissão pela rede de comunicação 719 através da antena 718. O DSP 720 não apenas processa os sinais de comunicação, mas também provê o controle do receptor e do transmissor. Por exemplo, os ganhos aplicados aos sinais de comunicação no receptor 712 e no transmissor 714 poderão ser adaptativamente controlados através de algoritmos de controle de ganho automáticos implementados no DSP 720.

A rede 719 poderá ainda comunicar com múltiplos sistemas, incluindo um servidor 760, como o servidor exemplar 104, e outros elementos (não mostrados). Por exemplo, a rede 719 poderá comunicar tanto com um sistema de empreendimento como um sistema de cliente da Web para acomodar um ou mais clientes com um ou mais níveis de serviço.

O UE 700 inclui um microprocessador 738 que controla a operação geral do dispositivo. Funções de comunicação, incluindo pelo menos comunicação de dados, são realizadas através do subsistema de comunicação 711. O microprocessador 738 também interage com outros subsistemas de dispositivo como a tela 722, memória flash 724, memória de acesso aleatório (RAM) 726, subsistemas auxiliares de entrada/saída (I/O) 728, porta serial 730, teclado 732, alto-falante 734, microfone 736, um subsistema de comunicação de curto alcance 740 e qualquer outro subsistema de dispositivo geralmente designado como 742.

Alguns dos subsistemas mostrados na Figura 7 efetuam funções relacionadas com a comunicação, enquanto outros subsistemas poderão fornecer funções "residentes" ou no dispositivo. Notadamente, alguns subsistemas, como o teclado 732, e a tela 722, por exemplo, poderão ser utilizados tanto para funções relacionadas com a comunicação, como entrar com mensagem de texto para transmissão pela rede de comunicação, e funções residentes no dispositivo, como uma calculadora ou lista de tarefas. O software de sistema operacional utilizado pelo microprocessador 748 poderá ser armazenado em um armazém persistente como a memória flash 724, que poderá, em vez disso, ser uma memória de apenas leitura (ROM) ou elemento de armazenamento similar (não mostrado). Aqueles dotados de habilidade ordinária na tecnologia apreciarão que o sistema operacional, aplicações específicas de dispositivo, ou partes das mesmas, poderão ser temporariamente carregadas em uma memória volátil como a RAM 726 . Sinais de comunicação recebidos também poderão ser armazenados na RAM 726. Ainda, um identificador singular também é preferivelmente armazenado na memória de apenas leitura.

Como é mostrado, a memória flash 724 pode ser segregada em diferentes áreas tanto para programas de computador 758 e armazenamento de dados de programa 750, 752, 754 e 756. Esses tipos de armazenamento diferentes indicam que cada programa pode alocar uma parcela da memória flash 724 para seus próprios requisitos de armazenamento de dados. A memória flash 724 adicionalmente inclui um módulo analisador de caixa objeto 770, um módulo monitor de estado sem fio 772, um módulo de limites operacionais 774, e um módulo seletor de mídia 776. O módulo analisador de caixa objeto 770 analisa arquivos 3GPP recebidos do servidor 104 para identificar uma ou mais caixas objeto de interesse. Por exemplo, o módulo analisador de caixa objeto 770 poderá ser configurado para identificar uma instância da caixa "meta" 308 e extrair o conteúdo dela para identificar opções de configuração de mídia codificada disponíveis para streaming. As opções de mídia disponíveis extraídas da uma ou mais caixas objeto analisadas poderá ser armazenada em uma memória, como, por exemplo, a memória flash 724 para posterior recuperação e/ou seleção. Como foi descrito acima, a posterior recuperação e/ou seleção de opções de mídia alternativas tendo conteúdo de mídia alternativo poderá ocorrer quando as condições de canal do UE 102 exemplar tornar-se insatisfatória. O monitor de estado sem fio exemplar 772 monitora as condições operacionais do UE 900 e compara os valores mensurados a um ou mais limites no módulo de limites operacionais 774. Valores mensurados que poderão indicar a qualidade do serviço e/ou a capacidade correspondente de renderizar mídia satisfatoriamente ao usuário do UE 700 incluem, sem a eles se limitar, uma velocidade de bit, um valor de latência, e/ou um valor de jitter. No evento de um ou mais eventos medidos superar o valor limite (por exemplo, cai abaixo de um limite aceitável de nível mais baixo, aumenta acima de um nível mais alto de limite aceitável), o módulo monitor de estado sem fio exemplar 772 poderá orientar o módulo seletor de mídia 776 a invocar o subsistema de comunicação 711 para recuperar mídia alternativa mais adequada para as condições operacionais atuais (por exemplo, selecionar um arquivo 3GPP tendo uma resolução mais baixa). A Figura 8 representa um diagrama de fluxo exemplar representativo de instruções lidas por computador que poderão ser utilizadas para facilitar a adaptação sem sessão controlada pelo cliente. As operações exemplo da Figura 8 poderão ser efetuadas utilizando um processador, uma controladora e/ou qualquer outro dispositivo de processamento adequado. Por exemplo, as operações exemplares da Figura 8 poderão ser implementadas utilizando instruções codificadas armazenadas em um meio tangível como a memória flash, a memória de apenas leitura (ROM) e/ou a memória de acesso aleatório (RAM) associada a um processador (por exemplo, o processador 738 da Figura 7 e/ou o processador 502 da Figura 5) . Alternativamente, parte ou a totalidade das operações exemplares da Figura 8 poderão ser implementadas utilizando qualquer combinação de circuito integrado específico da aplicação (ASICs), dispositivo lógico programável (PLD), dispositivo lógico programável no campo (FPLD), lógica discreta, hardware, firmware, etc. Outrossim, parte ou a totalidade das operações exemplares da Figura 8 poderão ser implementadas manualmente ou como qualquer combinação de qualquer uma das técnicas anteriores, por exemplo, qualquer combinação de firmware, software, lógica discreta e/ou hardware. Ainda, embora as operações exemplares da Figura 8 são descritas com referência ao diagrama de fluxo da Figura 8, outros métodos de implementar as operações da Figura 8 poderão ser empregados. Por exemplo, a ordem de execução dos blocos poderá ser modificada, e/ou alguns dos blocos descritos poderão ser modificados, eliminados, sub-divididos, ou combinados. Adicionalmente, qualquer uma ou a totalidade das operações exemplares da Figura 9 poderão ser efetuadas sequencialmente e/ou em paralelo, por exemplo, por fios de processamento separados, processadores, dispositivos, lógica discreta, circuitos, etc.

Em geral, o diagrama de fluxo exemplar da Figura 8 pode ser utilizado para implementar o UE exemplar da Figura 7 e/ou os intercâmbios exemplares 100, 200 e 250 das Figuras 1, 2A, e 2B. 0 processo exemplar 800 da Figura 8 transmite uma solicitação de mídia sem sessão (bloco 802) para iniciar uma instância do rendering da mídia no UE exemplar 102, 700. Em resposta a enviar a solicitação de mídia sem sessão (bloco 802), o UE exemplar 102 recebe um arquivo de mídia 3GPP associado à solicitação (bloco 804) . Como foi descrito acima, o arquivo de mídia associado poderá ser recebido com base em uma URL fornecida pelo usuário do UE 102, 700 e/ou em resposta a um enlace da Web selecionado pelo usuário. O arquivo de mídia 3GPP predefinido é analisado pelo analisador de caixa objeto exemplar 770 para extrair uma ou mais caixas objeto de interesse (bloco 806). Em particular, o analisador de caixa objeto 770 poderá ser configurado para identificar a ocorrência da caixa "meta" 308 e extrair metadados nela contida. Adicional ou alternativamente, o analisador de caixa objeto exemplar 770 poderá identificar uma URL embutida como metadados e/ou associada ao campo "u=" da caixa "hnti" exemplar 402.

Quando da obtenção de metadados associados ao arquivo 3GPP recebido, o analisador de caixa objeto exemplar 770 poderá identificar uma ou mais opções de configuração de mídia codificada alternativa disponível ao UE 102, 700 (bloco 8 08) . Por exemplo, o metadado analisado poderá identificar que um ou mais arquivos 3GPP alternativos estão disponíveis no servidor que têm um ou mais graus alternados de resolução e/ou de velocidade de bit. O metadado analisado poderá também identificar um ou mais locais (por exemplo, URLs) associados a cada mídia alternativa disponível. Para determinar se o arquivo 3GPP predefinido recebido (bloco 804) ê apropriado para as condições de canal do UE atual 102, 7 00, o monitor de estado sem fio exemplar 772 mede uma ou mais condições operacionais do UE e as compara a um ou mais limites operacionais armazenados no módulo de limites operacionais 774 (bloco 810) . Adicional ou alternativamente, o monitor de estado sem fio exemplar 772 poderá medir uma ou mais condições operacionais do UE associadas às capacidades de desempenho do UE. As capacidades de desempenho do UE poderão incluir, mas não estão limitados a uma velocidade em que o UE poderá renderizar um fluxo de bits antes do transbordamento da memória provisória e/ou a resolução máxima que o UE pode processar/renderizar. Se a comparação com o um ou mais limites indicar que um arquivo 3GPP alternativo não é necessário (por exemplo, porque as condições operacionais atuais e/ou o desempenho das capacidades do UE não violam um ou mais limites) (bloco 812), então o módulo seletor de mídia exemplar 776 permite que o arquivo 3GPP predefinido stream e/ou de outra forma renderizar no UE 102, 700 (bloco 814). Por outro lado, no evento de um arquivo 3GPP alternativo deva ser selecionado (bloco 812) (por exemplo, porque as condições de canal associadas ao UE 102, 700 são ruins), então o módulo seletor de mídia exemplar 776 invoca o subsistema de comunicação exemplar 711 para iniciar uma solicitação HTTP para o servidor 104 para o arquivo 3GPP alternativo (bloco 816). Como foi descrito acima, a solicitação HTTP subsequente para o servidor poderá incluir uma URL alternativa obtida da identificação anterior de opções de configuração de mídia codificada alternativa (bloco 808) .

O diagrama de fluxo exemplar da Figura 9 pode ser utilizado para implementar o servidor exemplar 104 da Figura 5 e/ou o gerente de arquivo de mídia exemplar 512 das Figuras 5 e 6, e/ou os intercâmbios exemplares 100, 200, e 250 das Figuras 1, 2A, e 2B. O processo exemplar 900 da Figura 9 monitora por um ou mais solicitações HTTP sem sessão (bloco 902). Se nenhuma solicitação for recebida, o processo exemplar 900 da Figura 9 continua a aguardar, caso contrário o gerente de caixa objeto exemplar 602 da Figura 6 constrói e/ou de outra forma enche uma ou mais caixas objeto associadas ao arquivo 3GPP solicitado (bloco 904). Como foi descrito acima, caixas objeto de um ou mais arquivos 3GPP poderão ser dispostas e/ou construídas pela pessoa responsável (por exemplo, um televisionador) para o conteúdo da mídia. O servidor exemplar 104, através do subsistema de comunicação 510, transmite o arquivo 3GPP para o UE solicitante através de HTTP sem sessão (por exemplo, em resposta a um comando HTTP GET) (bloco 906) e, se a mídia não estiver associada a um evento ao vivo (bloco 908) , o servidor exemplar 104 está acabado e continua a aguardar por outras solicitações (bloco 902) . Sem limitação, um sinalizador de conteúdo armazenado poderá ser empregado para indicar se o criador do conteúdo de mídia permite armazenamento local. Se não, o conteúdo poderá ser apagado após ele ser renderizado pelo UE exemplar 102, 700. Diferentemente do streaming tradicional através do RTSP, os métodos e aparelho aqui descritos não inundam o servidor com responsabilidades de processamento onerosas de criar, manter, e/ou fechar uma sessão para cada conexão ativa. Como tal, servidores empregados com os métodos e aparelho aqui descritos poderão custar menos do que os servidores de mídia que facilitam o streaming RTSP.

No evento de que o conteúdo de mídia é associado a um evento ao vivo (bloco 908), o atualizador de metadados streaming ao vivo exemplar 604 atualiza o meta-arquivo- fluxo-ao vivo para refletir o valor do índice de fragmento do arquivo atual e o valor do recuo de dados atual (bloco 910) . Como foi descrito acima, o UE 102, 700 poderão consultar o servidor 104 para obter esses valores atuais para permitir a busca de mídia ao vivo (por exemplo, HTTP GET) . 0 gerente de arquivo de mídia exemplar 512 aguarda por um sinal manual, um sinal periódico, aperiódico, e/ou período de tempo cronogramado (bloco 912) e determina se o evento de mídia ao vivo está acabado (bloco 914). Se não, o atualizador de metadados streaming ao vivo 804 atualiza o meta-arquivo-fluxo-ao vivo para refletir os valores índice de fragmento do arquivo atual e o valor do recuo de dados atual (bloco 810), caso contrário o servidor exemplar 104 aguarda por outra solicitação (bloco 902). Em outros exemplos, o provedor de conteúdo de mídia (por exemplo, um televisionador) é responsável por atualizar (por exemplo, prepending) o meta-arquivo-fluxo-ao vivo. 0 microprocessador 738, além de suas funções de sistema operacional, preferivelmente permite a execução de aplicações de software no dispositivo móvel. Um conjunto predeterminado de aplicações que controlam operações básicas, incluindo pelo menos aplicações de comunicação de voz e de dados, por exemplo, normalmente serão instaladas no UE 700 durante a fabricação. Uma aplicação de software preferida poderá ser uma aplicação de gerente de informação pessoal (PIM) tendo a capacidade de organizar e gerenciar itens de dados relacionados ao usuário do dispositivo móvel, como, mas não limitado, a correspondência eletrônica, eventos de calendário, correspondência por voz, compromissos, e itens de tarefa. Naturalmente, uma ou mais armazéns de memória estariam disponíveis no dispositivo móvel para facilitar o armazenamento de itens de dados PIM.

Essa aplicação PIM preferivelmente teria a capacidade de enviar e de receber itens de dados, através da rede sem fio 719. Em uma versão preferida, os itens de dados PIM são integrados com perfeição, sincronizados e atualizados, através da rede sem fio 719, com os itens de dados correspondentes do usuário do dispositivo móvel armazenados ou associados a um sistema de computador hospedeiro. Outras aplicações também poderão ser carregadas no dispositivo móvel 700 através da rede 719, um subsistema auxiliar de I/O 728, porta serial 730, subsistema de comunicação de curto alcance 740 ou qualquer outro subsistema adequado 742 e instalado por um usuário na RAM 726 ou preferivelmente em armazém não-volátil (não mostrado) para execução pelo microprocessador 738. Essa flexibilidade na instalação da aplicação aumenta a funcionalidade do dispositivo e poderá fornecer funções aprimoradas no dispositivo, funções relacionadas com a comunicação, ou os dois. Por exemplo, aplicações de comunicação segura poderão permitir funções de comércio eletrônico e outras transações financeiras dessas sejam efetuadas utilizando o UE 700. Essas aplicações, contudo, de acordo com o que antecede, em muitos casos precisarão ser aprovadas por uma portadora.

No modo de comunicação de dados, um sinal recebido como uma mensagem de texto ou baixa de página da Web será processada pelo subsistema de comunicação 711 e entrado no microprocessador 738, que preferivelmente ainda processa o sinal recebido para saída para a tela 722 ou alternativamente para um dispositivo de I/O auxiliar 728. O usuário do UE 700 poderá também compor itens de dados como mensagens de correspondência eletrônica, por exemplo, utilizando o teclado 732, que é preferivelmente um teclado alfanumérico completo ou uma almofada de teclas do tipo telefone, em conjunto com a tela 722 e possivelmente um dispositivo de I/O auxiliar 728. Esses itens compostos poderão então ser transmitidos pela rede de comunicação através do subsistema de comunicação 711.

Para a comunicação de voz, a operação geral do UE 700 é similar, exceto que os sinais recebidos preferivelmente seriam emitidos para um alto-falante 734 e os sinais para a transmissão seriam gerados por um microfone 736 Subsistemas alternativos de I/O de voz ou de áudio, como o subsistema de gravação de mensagem de voz, também poderão ser implementados no UE 700. Embora a saída de sinal de voz ou de áudio seja preferivelmente realizada essencialmente através do alto-falante 734, a tela 722 poderá também ser utilizada para fornecer uma indicação da identidade da parte que chama, a duração de uma chamada de voz, ou outra informação relacionada à chamada de voz, por exemplo.

A porta serial 730 na Figura 7 normalmente seria implementada em um tipo de dispositivo móvel assistente digital pessoal (PDA) para o qual sincronização com o computador de mesa do usuário (não mostrado) poderá ser desejável. Tal porta 730 permitiria ao usuário fixar preferências através de um dispositivo externo ou aplicação de software e estenderia as capacidades do dispositivo móvel 700 ao fornecer informação ou baixas de software para o UE 7 00 que não através de uma rede de comunicação sem fio. A via de baixa alternativa poderá, por exemplo, ser utilizada para carregar uma chave de criptografia no dispositivo através de uma conexão direta, e assim confiável, para assim permitir a comunicação de dispositivo seguro.

Alternativamente, a porta serial 730 poderia ser utilizada para outras comunicações, e poderia incluir uma porta de barramento serial universal (USB). Uma interface é associada à porta serial 730.

Outros subsistemas de comunicação 740, como o subsistema de comunicação de curto alcance, é outro componente opcional que poderá prover a comunicação entre o UE 700 e sistemas ou dispositivos diferentes, que não necessariamente precisam ser dispositivos similares. Por exemplo, o subsistema 740 poderá incluir um dispositivo infravermelho e circuitos e componentes associados ou um módulo de comunicação Bluetooth® para prover a comunicação com sistemas e dispositivos similarmente ativados.

Embora certos métodos, aparelho, e artigos de fabricação foram descritos aqui, o escopo da cobertura desta patente não é limitado a isso. Pelo contrário, esta patente abrange todos os métodos, aparelho e artigos de fabricação que se enquadram razoavelmente dentro do escopo das reivindicações apensas quer literalmente ou sob a doutrina de equivalentes.

Claims

1. Método para transmissão de conteúdo de mídia via protocolo de transferência de hipertexto, o método caracterizado por compreender: recuperar metadados para uma pluralidade de codificações de conteúdo de mídia, em que os metadados incluem um primeiro localizador uniforme de recursos (URL) e um primeiro conjunto de bytes compensadores para uma primeira parcela do conteúdo de mídia com uma primeira codificação e uma segunda URL e um segundo conjunto de bytes compensadores para uma segunda parcela do conteúdo de mídia com uma segunda codificação, em que tanto a primeira quanto a segunda parcela contém um fragmento de filme baseado em um formato de arquivo de mídia base ISO; e solicitar a primeira parcela do conteúdo de mídia utilizando o primeiro URL e o primeiro conjunto de bytes compensadores.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que tanto a primeira parcela quanto a segunda parcela inclui pelo menos um de uma caixa moov, uma caixa moof, uma caixa ftyp, ou uma caixa de dados de mídia (mdat).

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que tanto o primeiro conjunto de bytes compensadores quanto o segundo conjunto de bytes compensadores incluem uma pluralidade de bytes, cada byte da pluralidade de bytes sendo contíguo um com o outro.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender a transferência da primeira parcela com base em uma condição de canal.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de ainda compreender a transferência da segunda parcela do conteúdo de mídia com base em uma mudança da condição de canal.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a segunda parcela é solicitada utilizando a segunda URL e o segundo conjunto de bytes compensadores.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender a transferência da primeira parcela do conteúdo de mídia baseado na capacidade de um dispositivo.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender a solicitação de uma terceira parcela do conteúdo de mídia usando a primeira URL.

9. Dispositivo para transmissão de conteúdo de mídia via protocolo de transferência de hipertexto, caracterizado pelo fato do dispositivo compreender: um processador configurado para: receber metadados para uma pluralidade de codificações de conteúdo de mídia, em que os metadados incluem um primeiro localizador uniforme de recursos (URL) e um primeiro conjunto de bytes compensadores para uma primeira parcela do conteúdo de mídia com uma primeira codificação e uma segunda URL e um segundo conjunto de bytes compensadores para uma segunda parcela do conteúdo de mídia com uma segunda codificação, em que tanto a primeira quanto a segunda parcela contém um fragmento de filme baseado em um formato de arquivo de mídia base ISSO; e solicitar a primeira parcela do conteúdo de mídia utilizando o primeiro URL e o primeiro conjunto de bytes compensadores.

10. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de que tanto a primeira parcela quanto a segunda parcela incluem pelo menos um de uma caixa moov, uma caixa moof, uma caixa ftyp, ou uma caixa de dados de mídia (mdat).

11. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de que tanto o primeiro conjunto de bytes compensadores quanto o segundo conjunto de bytes compensadores inclui uma pluralidade de bytes, cada bytes da pluralidade de bytes sendo contíguo um com o outro.

12. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de que o processador é ainda configurado para transferir a primeira parcela baseada em uma condição de canal.

13. Dispositivo, de acordo com a reivindicação 12, caracterizado pelo fato de que o processador é ainda configurado para transferir a segunda parcela de conteúdo de mídia baseada em uma mudança da condição de canal.

14. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de que a segunda parcela é solicitada usando uma segunda URL e um segundo conjunto de bytes compensadores.

15. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de que o processador ainda é configurado para transferir a primeira parcela do conteúdo de mídia baseado na capacidade do dispositivo.

16. Dispositivo, de acordo com a reivindicação 9, caracterizado pelo fato de o processador é ainda configurado para solicitar de uma terceira parcela do conteúdo de mídia usando a primeira URL.

17. Método para transmissão de conteúdo de mídia via protocolo de transferência de hipertexto, o método caracterizado por compreender: fornecimento de metadados para uma pluralidade de codificações de conteúdo de mídia, em que os metadados incluem um primeiro localizador uniforme de recursos (URL) e um primeiro conjunto de bytes compensadores para uma primeira parcela do conteúdo de mídia com uma primeira codificação e uma segunda URL e um segundo conjunto de bytes compensadores para uma segunda parcela do conteúdo de mídia com uma segunda codificação, em que tanto a primeira quanto a segunda parcelas contém um fragmento de filme baseado em um formato de arquivo de mídia base ISO, e a primeira parcela do conteúdo de mídia sendo fornecida utilizando a primeira URL e o primeiro conjunto de bytes complementares; e fornecer a primeira parcela em resposta a um comando GET.

18. Método, de acordo com a reivindicação 17, caracterizado pelo fato da primeira parcela ser fornecida com base na condição de canal.

19. Método, de acordo com a reivindicação 18, caracterizado pelo fato da segunda parcela do conteúdo de mídia ser fornecida com base em uma mudança da condição de canal.

20. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que a segunda parcela é fornecida utilizando a segunda URL e o segundo conjunto de bytes compensadores.

21. Método, de acordo com a reivindicação 17, caracterizado pelo fato de que a primeira parcela do conteúdo de mídia é fornecida com base na capacidade de um dispositivo.

22. Método, de acordo com a reivindicação 17, caracterizado pelo fato de compreender o fornecimento de uma terceira parcela do conteúdo de mídia usando a primeira URL.

23. Dispositivo para transmissão de conteúdo de mídia via protocolo de transferência de hipertexto, caracterizado pelo fato de compreender: um processador configurado para: fornecer metadados para uma pluralidade de codificações de conteúdo de mídia, em que os metadados incluem um primeiro localizador uniforme de recursos (URL) e um primeiro conjunto de bytes compensadores para uma primeira parcela do conteúdo de mídia com uma primeira codificação e uma segunda URL e um segundo conjunto de bytes compensadores para uma segunda parcela do conteúdo de mídia com uma segunda codificação, em que tanto a primeira quanto a segunda parcela contém um fragmento de filme baseado em um formato de arquivo de mídia base ISO, e a primeira parcela do conteúdo de mídia sendo fornecida usando a primeira URL e o primeiro conjunto de bits compensadores; e fornecer uma primeira parcela em resposta a um comando GET.

24. Dispositivo, de acordo com a reivindicação 23, caracterizado pelo fato da primeira parcela ser fornecida com base na condição de canal.

25. Dispositivo, de acordo com a reivindicação 24, caracterizado pelo fato da segunda parcela do conteúdo de mídia ser fornecida com base em uma mudança na condição de canal.

26. Dispositivo, de acordo com a reivindicação 23, 10 caracterizado pelo fato de que a segunda parcela é fornecida utilizando a segunda URL e o segundo conjunto de bytes complementares.

27. Dispositivo, de acordo com a reivindicação 23, caracterizado pelo fato de que a primeira parcela do 15 conteúdo de mídia é fornecida com base em uma capacidade de um segundo dispositivo.