BRPI1007814B1 - Método para reproduzir sem problemas a mídia em um cliente, sistema de computador para processamento de mídia sem problemas a partir de um evento ao vivo e dispositivo de armazenamento legível por computador - Google Patents

Abstract

variação contínua, meios de fluxo do cliente stateless um sistema adaptativo de fluxo é descrito neste documento que fornece uma conexão sem estado entre o cliente e o servidor para meios de reprodução de fluxo em que os dados são formatados de uma maneira que permite que o cliente tome decisões e reaja mais rapidamente às condições mutáveis da rede. o cliente solicita blocos uniformes dos meios de comunicação a partir do servidor, que incluem uma parcela da mídia. os pedidos de adaptação do sistema de blocos de partes de um arquivo de mídia ou de um evento ao vivo em pequenos blocos do tamanho de cada um com um url distinto. isso permite que os meios de fluxo de dados sejam armazenados por infra-estrutura existente da internet cache. cada bloco contém informações de metadados que descreve a codificação do bloco e de conteúdo de mídia para a reprodução pelo cliente. o servidor pode fornecer blocos em várias codificações para que o cliente possa mudar rapidamente aos blocos de uma taxa de bit diferente ou velocidade de reprodução.

Description

Fundamento

[0001] Meios de fluxo são multimídias que estão constantemente recebidas e normalmente apresentadas, por um usuário final (usando um cliente) enquanto ele está sendo entregue por um provedor de fluxo (usando um servidor). Vários protocolos existem para meios de fluxo, incluindo o Tempo-Real Protocolo de Fluxo (RTSP), Tempo-Real Protocolo deTransporte (RTP), e o Tempo-Real Protocolo de Controle de Transporte (RTCP), que aplicações de fluxo utilizam frequentemente juntos. O Tempo-Real Protocolo de Fluxo (RTSP), desenvolvido pela Internet Força-Tarefa de Engenharia (IETF) e criado em 1998 como Pedido de Comentários (RFC) 2326, é um protocolo para uso em sistemas de meios de fluxo, que permite que um cliente possa controlar remotamente um servidor de meios de fluxo, emissão de VCR-tipo comandos como "play" e "pause", e permitindo que o tempo de acesso seja baseado em arquivos em um servidor.

[0002] O envio de fluxo de dados em si não é parte do protocolo RTSP. A maioria dos servidores RTSP usam o RTP baseado em padrões como o protocolo de transporte para o real de áudio / vídeo de dados, atuando tanto como um canal de metadados. RTP define um formato de pacote padronizado para a entrega de áudio e vídeo através da Internet. RTP foi desenvolvido pelo Grupo de Transporte Áudio- Vídeo de trabalho da IETF e publicado pela primeira vez em 1996 como RFC 1889, e substituído pelo RFC 3550 em 2003. O protocolo é similar em sintaxe e operação para Hipertexto Transporte Protocolo (HTTP), mas RTSP acrescenta novas solicitações. Enquanto HTTP é stateless, RTSP é um protocolo stateful. RTSP usa um ID de sessão para manter o controle de sessões, quando necessário. Mensagens RTSP são enviadas do cliente ao servidor, embora existam algumas exceções em que o servidor irá enviar mensagens para o cliente.

[0003] Aplicações de fluxo RTP costumam usar em conjunto com o RTCP. Enquanto carrega a RTP fluxos de mídia (por exemplo, áudio e vídeo) ou fora da faixa de sinalização (tom dual-multi-frequência (DTMF)), aplicações de fluxo de uso RTCP para monitorar as estatísticas de transmissão e qualidade de serviço (QoS) de informação. RTP permite apenas um tipo de mensagem, que carrega os dados da origem para o destino. Em muitos casos, há uma necessidade de outras mensagens em uma sessão. Estas mensagens de controle do fluxo e da qualidade dos dados permitem que o destinatário possa enviar um feedback para a fonte ou fontes. RTCP é um protocolo projetado para esta finalidade. RTCP possui cinco tipos de mensagens: relatório do remetente, o relatório receptor, mensagem de descrição da fonte, a mensagem de adeus, e aplicações específicas da mensagem. RTCP fornece informações fora de banda de controle para um fluxo RTP e parceiros com a RTP na entrega e embalagem dos dados multimídia, mas não transportam quaisquer dados em si. Aplicações de fluxo de uso RTCP periodicamente transmitem pacotes de controle aos partici-pantes de uma sessão multimídia de fluxo. Uma das funções do RTCP é fornecer feedback sobre a qualidade do serviço RTP está fornecendo. RTCP reúne estatísticas sobre uma conexão de mídia e informações como bytes enviados, pacotes enviados, pacotes perdidos, jitter, feedback, e atraso de ida e volta. Um aplicativo pode usar essa informação para aumentar a qualidade do serviço, talvez pela limitação de fluxo ou usando um codec diferente ou taxa de bits.

[0004] Um problema com o fluxo de mídia existente de arquitetu- ras é a forte ligação entre o servidor e o cliente. A conexão stateful entre cliente e servidor cria a sobrecarga do servidor adicional, porque o servidor controla o estado atual de cada cliente. Isso também limita a escalabilidade do servidor. Além disso, o cliente não pode reagir rapidamenteàs mudanças de condições, tais como perda de pacotes aumentados, a largura de banda reduzida, as solicitações do usuário para um conteúdo diferente ou modificar o conteúdo existente (por exemplo, acelerar ou retroceder), e assim por diante, sem antes comunicar com o servidor e à espera do servidor para se adaptar e responder. Muitas vezes, quando um cliente relata uma menor largura de banda disponível (por exemplo, através de RTCP), o servidor não se adapta rapidamente causando rupturas na mídia para ser notado pelo usuário no cliente como pacotes que excedem a largura de banda disponível não são recebidos e novas dos pacotes de baixa taxa de bits não são enviados a partir do servidor no tempo. Para evitar esses problemas, os clientes muitas vezes usam dados de buffer, mas o buffer introduz latência, o que para eventos ao vivo pode ser inaceitável.

[0005] Além disso, a Internet contém vários tipos de itens para download de conteúdo de mídia, incluindo áudio, vídeo, documentos, e assim por diante. Esses itens de conteúdo são geralmente muito grandes como vídeos em centenas de megabytes. Os usuários geralmente recuperam documentos através da Internet usando HTTP através de um navegador web. A Internet tem construído uma grande infra- estrutura de roteadores e proxies que são eficazes no cache de dados para HTTP. Os servidores podem fornecer dados em cache para os clientes com menos atrasos e usando menos recursos do que re- solicitando o conteúdo da fonte original. Por exemplo, um usuário em Nova York pode fazer download de um item de conteúdo servido de um host no Japão, e receber o item de conteúdo através de um roteador na Califórnia. Se um usuário em Nova Jersey solicita o mesmo ar- quivo, o roteador na Califórnia pode ser capaz de fornecer o item de conteúdo, sem novamente solicitar os dados do host no Japão. Isso reduz o tráfego de rede em rotas possivelmente esticadas, e permite ao usuário, em Nova Jersey para receber o item de conteúdo com menoslatência.

[0006] Infelizmente, a mídia ao vivo muitas vezes não pode ser armazenada em cache usando os protocolos existentes, e cada cliente solicita a mídia do mesmo servidor ou conjunto de servidores. Além disso, quando meios de fluxo pode ser armazenada em cache, cache de hardware especializado é frequentemente envolvido, ao invés de infra-estrutura de Internet existente e disponível com base em HTTP caching. A falta de cache limita o número de espectadores simultâneos e solicita que os servidores podem manusear, e limita a participação de um evento ao vivo. O mundo está cada vez mais usando a internet para consumir até as informações minutos ao vivo, como o número recorde de usuários que assistiu eventos ao vivo, como a abertura dos Jogos Olímpicos de 2008 através da Internet. As limitações da tecnologia atual estão retardando a adoção da Internet como um meio para consumir este tipo de conteúdo de mídia.

Sumário

[0007] Um sistema adaptativo de fluxo é descrito neste documento que fornece uma conexão sem estado entre o cliente e o servidor para meios de reprodução de fluxo em que os dados são formatados de uma maneira que permite que o cliente tome decisões tradicionalmente desempenhadas pelo servidor e, portanto, reagir mais rapidamente às mudanças das condições da rede. O cliente solicita blocos uniformes dos meios de comunicação a partir do servidor, que incluem uma parcela da mídia. Os pedidos de adaptação do sistema de fluxo de partes de um arquivo de mídia ou de um evento ao vivo em pequenos blocos do tamanho de cada um com um URL distinto. Isto permite in- fra-estrutura de cache existente da Internet para armazenar em cache meios de fluxo, permitindo assim que mais clientes possam ver o mesmo conteúdo na mesma época. Como o evento progride, o cliente continua solicitando blocos até o final do evento ou mídia. Cada bloco contém informações de metadados que descreve a codificação do bloco e de conteúdo de mídia para a reprodução pelo cliente. O servidor pode fornecer blocos em várias codificações para que o cliente possa mudar rapidamente a blocos de uma taxa de bit diferentes ou velocidade de reprodução. Assim, o sistema adaptativo de fluxo fornece uma experiência aprimorada para o usuário com menos quebras em meios de fluxo de reprodução, e uma maior probabilidade de que o cliente receberá a mídia com menor latência de um servidor de cache local.

[0008] Este resumo é fornecido para apresentar uma seleção de conceitos de uma forma simplificada que estão descritos abaixo na descrição detalhada. Este sumário não se destina a identificar as ca- racterísticas-chave ou características essenciais da matéria reivindicada, nem é destinado a ser usado para limitar o escopo da matéria reivindicada.

Breve Descrição dos Desenhos

[0009] Figura 1 é um diagrama de blocos que ilustra os componen tes do sistema adaptativo de fluxo, em uma modalidade.

[00010] Figura 2 é um diagrama de blocos que ilustra um ambiente operacional do sistema de transmissão de variação contínua usando a Microsoft Windows e IIS, em uma modalidade.

[00011] Figura 3 é um diagrama que ilustra o fluxo de processamento do sistema de adaptação de fluxo em um cliente para a repro dução de mídia, em uma modalidade.

[00012] Figura 4 é um diagrama que ilustra o fluxo de processamento do sistema de adaptação de fluxo para lidar com um bloco úni co de mídia, em uma modalidade.

Descrição Detalhada

[00013] Um sistema adaptativo de fluxo é descrito neste documento que fornece uma conexão sem estado entre o cliente e o servidor para meios de reprodução de fluxo em que os dados são formatados de uma maneira que permite que o cliente tome decisões muitas vezes deixadas para o servidor em protocolos passados, e, portanto, reagir mais rapidamente às condições mutáveis da rede. Além disso, o sistema adaptativo de fluxo funciona de uma forma que permite infra- estrutura de cache existente na Internet para armazenar em cache de dados os meios de fluxo, permitindo que mais clientes possa ver o mesmo conteúdo na mesma época. Os pedidos de adaptação do sistema de fluxo das partes de um arquivo de mídia ou de um evento ao vivo em pequenos blocos do tamanho de cada um com um URL distinto. Cada bloco pode ser um arquivo de mídia em seu próprio direito, ou pode ser parte de um arquivo de mídia inteira. Como o evento progride, o cliente continua solicitando blocos até o final do evento. Cada bloco contém informações de metadados que descreve a codificação do bloco e de conteúdo de mídia para a reprodução pelo cliente. O servidor pode fornecer blocos em várias codificações para que o cliente possa, por exemplo, alternar rapidamente a blocos de uma taxa de bit diferentes ou velocidade de reprodução. Porque os blocos de aderir a World Wide Web Consortium Padrões (W3C) HTTP, os blocos são pequenos o suficiente para ser armazenado em cache, e o sistema fornece os blocos da mesma forma a cada cliente, os blocos são naturalmente em cache por infra-estrutura existente na Internet, sem modificação. Assim, o sistema adaptativo de fluxo fornece uma experiência aprimorada para o usuário com menos quebras em meios de fluxo de reprodução, e uma maior probabilidade de que o cliente receberá a mídia com menor latência de um servidor de cache local. Porque a conexão entre o cliente e o servidor é stateless, o mesmo cliente e servi- dor não precisam ser ligados para a duração de um evento de muito tempo. O sistema aqui descrito stateless não tem afinidade servidor, permitindo que os clientes juntem manifestações de servidores que podem ter começado em tempos diferentes, e também permitir que os administradores do servidor para abrir ou fechar servidores de origem como manda a carga.

[00014] Em algumas modalidades, o sistema adaptativo de fluxo utiliza um formato de nova transmissão de dados entre o servidor e o cliente. O cliente solicita blocos de mídia de um servidor que incluem uma parcela da mídia. Por exemplo, para a 10 - arquivo minuto, o cliente pode solicitar 2 segundos blocos. Observe que, diferentemente de fluxo típico em que o servidor envia dados para o cliente, neste caso o cliente puxa blocos de mídia a partir do servidor. No caso de uma transmissão ao vivo, o servidor pode estar criando a mídia on the fly e produzir blocos respondendo às solicitações do cliente. Assim, o clientesó pode ser vários blocos por trás do servidor em termos de quão rápido o servidor cria blocos e quão rápido são os blocos de pedidos do cliente.

[00015] Cada bloco contém metadados e conteúdo de mídia. Os metadados podem descrever informações úteis sobre o conteúdo de mídia, tais como a taxa de bits do conteúdo de mídia, onde o conteúdo de mídia se encaixa em um elemento de mídia maiores (por exemplo, este bloco representa offset 1: 10 em um clipe de vídeo de 10 minutos), o codec utilizado para codificar o conteúdo de mídia, e assim por diante. O cliente usa essas informações para colocar o bloco em um storyboard do elemento media maiores e de decodificar corretamente e reprodução do conteúdo de mídia.

[00016] Figura 1 é um diagrama de blocos que ilustra os componentes do sistema adaptativo de fluxo, em uma modalidade. O sistema adaptativo de fluxo 100 inclui um componente pedido bloco 110, um componente de análise bloco 120, um componente de montagem manifesta 130, um componente de reprodução de mídia 140, um componente de monitorização de QoS 150, e um componente de sincronização do relógio 160. Cada um destes componentes é descrito em mais detalhes aqui. O sistema adaptativo de fluxo 100, como aqui descrito opera principalmente em um sistema de computador cliente. No entanto, aqueles versados na técnica vão reconhecer que vários componentes do sistema podem ser colocados em vários locais dentro de um ambiente de rede para fornecer conteúdo específico de resultados positivos.

[00017] O componente pedido bloco 110 faz solicitações do cliente para blocos individuais de mídia a partir do servidor. Conforme mostrado na Figura 2, o pedido do cliente pode passar primeiro a um servidor de borda (por exemplo, um cache de Internet), em seguida, para um servidor de origem, e depois a um servidor ingerir. Em cada fase, se os dados solicitados são encontrados, então o pedido não ir para o próximo nível. Por exemplo, se o servidor de borda tem os dados solicitados e, em seguida o cliente recebe os dados do servidor de borda e o servidor de origem não recebe o pedido. Cada bloco pode ter um Uniforme Recurso Localizador (URL) que, individualmente, identifica o bloco. Servidores cache de internet são bons em cache de respostas a solicitações de URL do servidor específico (por exemplo, HTTP GET). Assim, quando o primeiro cliente de chamadas através do servidor para obter um bloco, a borda de cache servidores que bloco e posterior de clientes que solicitam a mesma quantidade pode receber o bloco do servidor de borda (com base no tempo de vida do cache e tempo de servidor para viver (TTL) configurações). O componente pedido do bloco 110 recebe o bloco e passa para o componente de análise do bloco 120 para interpretação.

[00018] O componente de análise do bloco 120 interpreta o formato de um bloco de mídia recebida pela solicitação de componente bloco 110 e separa o bloco em suas partes componentes. Tipicamente, o bloco inclui uma parte de cabeçalho contendo metadados, e uma porção de dados que contenha conteúdo de mídia. O componente de análise do bloco fornece os metadados para a montagem de componentes manifestados e 130 o conteúdo de mídia com o componente mídia playback 140.

[00019] O componente de montagem manifestado 130 constrói um manifesto que descreve o elemento de mídia para o qual recebeu o conteúdo de mídia pertence. Grandes arquivos de mídia que os clientes de download como um todo (ou seja, não fluxo) muitas vezes inclui um manifesto descrevendo todo o arquivo, os codecs e taxas de bits usados para codificar várias partes do arquivo, marcadores de posições significativas com o arquivo, e assim por diante. Durante a transmissão de conteúdo, especialmente ao vivo, um servidor não pode fornecer um manifesto completo porque o evento ainda está em curso. Assim, o servidor fornece o máximo de manifestação como ele pode através dos metadados no bloco de mídia. O servidor também pode fornecer uma interface de programação de aplicativos (API), como uma URL pré-definida, para que o cliente solicite o manifesto até o ponto atual no fluxo de mídia. Isto pode ser útil quando o cliente se junta a um evento, transmitido ao vivo após o evento que já está em andamento. O manifesto permite ao cliente solicitar previamente transmição de porções do elemento de mídia (por exemplo, rebobina- mento), e o cliente continua a receber novas porções do manifesto através do metadados dos pedaços de mídia de fluxo.

[00020] O componente de montagem manifestado 130 constrói um manifesto semelhante ao disponível para um arquivo de mídia completo. Assim, como o produto caso, se o usuário quiser ignorar ao contrário na mídia (por exemplo, retroceder ou avançar para uma posição particular), em seguida, avançar novamente, o usuário pode fazê-lo e o cliente usa o manifesto reunido para encontrar o bloco apropriado ou blocod de reprodução para o usuário. Quando o usuário faz uma pausa, o sistema 100 pode continuar a receber blocos de mídia (ou apenas a parte de blocos de metadados baseado em uma URL pedido distinto), para que o componente de montagem manifestado 130 possa continuar a construir o manifesto e estar pronto para qualquer solicitação do usuário (por exemplo, passe para a posição atual ao vivo ou jogar a partir do ponto de pausa) depois que o usuário fez uma pausa. O manifesto do lado do cliente montado permite que o cliente possa jogar o evento de mídia ao contrário como conteúdo do pedido, assim como o evento é longo, e para pular dentro do evento de mídia como está acontecendo.

[00021] O componente de reprodução de mídia 140 reproduz conteúdo de mídia recebido usando o hardware do cliente. O componente de reprodução de mídia 140 pode invocar um ou mais codecs para interpretar o recipiente dentro do qual o conteúdo de mídia é transportado e para descomprimir ou decodificar o conteúdo de mídia a partir de um formato comprimido para um formato cru (por exemplo, YV12, RGBA, ou amostras de áudio PCM ) prontos para reprodução. O componente de reprodução de mídia 140 pode então fornecer a matéria- prima formato de conteúdo de mídia a uma API do sistema operacional (por exemplo, Microsoft DirectX) para reprodução de som em locais do sistema de informática e hardware de vídeo, como uma tela e alto- falantes.

[00022] O componente de monitorização de QoS 150 analisa o sucesso de receber pacotes do servidor e adapta os pedidos do cliente com base em um conjunto de rede atuais e outras condições. Por exemplo, se o cliente é rotineiramente recebido por blocos de mídia final, então o componente 150 pode determinar que a largura de banda entre o cliente e o servidor é inadequada para a taxa de bit, e o cli- ente pode começar a pedir blocos de mídia a uma taxa de bits mais baixa. Monitoramento de QoS podem incluir medição de heurísticas, tais como taxa de tornar frame, tamanho da janela, tamanho do buffer, a freqüência de rebuffering, e assim por diante. Blocos de mídia para cada taxa de bits pode ter um URL distinto para que blocos de várias taxas de bits possam são armazenados em cache pela infra-estrutura de cache Internet. Observe que o servidor não controla o estado do cliente e não sabe qual a taxa de bit qualquer do cliente específico que está jogando atualmente. O servidor pode simplesmente fornecer o mesmo elemento de mídia em uma variedade de taxas de bits para satisfazer pedidos de clientes potenciais sob uma variedade de condições. Além disso, a inicial se manifesta e / ou metadados que o cliente recebe pode incluir informações sobre as taxas de bits e propriedades de codificação de outros disponíveis a partir do servidor, para que o cliente possa escolher a codificação que irá proporcionar uma experiência de cliente bom.

[00023] Note que ao mudar as taxas de bit, o cliente simplesmente começa solicitando a nova taxa de bits e reproduz os blocos novos da taxa de bits como o cliente recebe os blocos. O cliente não tem de enviarinformações de controle para o servidor e aguardar o servidor para adaptar o fluxo. A solicitação do cliente não pode mesmo chegar ao servidor devido a um esconderijo entre o cliente e o servidor satisfazer o pedido. Assim, o cliente é muito mais rápido a reagir do que os clientes nos meios de comunicação tradicionais dos sistemas de transmissão, e os encargos para o servidor têm clientes diferentes de ligação sob várias condições de corrente são reduzidos drasticamente. Além disso, devido as condições atuais tendem a ser localizado, é provável que muitos clientes em uma determinada região geográfica ou de um determinado fornecedor de serviços de Internet (ISP) vai experimentar condições similares e irá solicitar codificações similares de mídia (por exemplo, as taxas de bit). Porque caches também tendem a ser localizados,é provável que os clientes em uma determinada situação vai achar que o cache perto deles é "quente" com os dados de cada pedido, de modo que a latência experimentada por cada cliente será baixo.

[00024] O componente de sincronização do relógio 160 sincroniza os relógios do servidor e do cliente. Embora o tempo absoluto não é geralmente relevante para o cliente e servidor, sendo capaz de identificar um bloco particular e saber a taxa (ou seja, a cadência) em que a solicitação de blocos é relevante para o cliente.

[00025] Por exemplo, se os pedidos dos dados do cliente seja muito rapidamente, o servidor não terá ainda os dados e vai responder com respostas de erro (por exemplo, um HTTP 404 não encontrado de resposta de erro) a criação de muitos pedidos espúrios que consume desnecessariamente da largura de banda. Por outro lado, se os pedidos dos dados do cliente seja muito devagar, então o cliente pode não ter os dados em tempo para a reprodução que cria quebras de notável na mídia reproduzido para o usuário. Assim, o cliente e o servidor funcionam bem quando o cliente sabe a taxa na qual o servidor está produzindo novos blocos e sabe onde o bloco atual se encaixa no crono- grama geral. O componente de sincronização do relógio 160 fornece essas informações, permitindo que o servidor e o cliente tenham um valor de relógio semelhante em um determinado momento. O servidor também pode marcar cada bloco de mídia com o momento em que o servidor criou o bloco.

[00026] A sincronização do relógio também dá ao servidor uma referência comum em cada um dos codificadores. Por exemplo, o servidor pode codificar dados em taxas de bits múltiplos e usando vários codecs ao mesmo tempo. Cada codificador pode fazer referência a dados codificados de uma maneira diferente, mas a hora pode ser definida em comum em todos os codificadores. Desta forma, se um cliente solicita um bloco particular, o cliente terá de mídia que representa o mesmo período, independentemente da codificação que o cliente seleciona.

[00027] O dispositivo de computação em que o sistema é implementado pode incluir uma unidade de processamento central, memória, dispositivos de entrada (por exemplo, teclado e dispositivos apontadores), dispositivos de saída (por exemplo, dispositivos de vídeo), e dispositivos de armazenamento (por exemplo, unidades de disco ou outras organizações não- voláteis de mídia de armazenamento). Os dispositivos de memória e armazenamento são meios legíveis por computador de armazenamento que podem ser codificados com computadorexecutável de instruções (por exemplo, software) que imple-mentam ou ativam o sistema. Além disso, as estruturas de dados e estruturas de mensagens podem ser armazenados ou transmitidos através de um meio de transmissão de dados, como um sinal em um link de comunicação. Vários links de comunicação podem ser utilizadas, tais como a Internet, uma rede de área local, uma rede de área ampla, um ponto-a-ponto de conexão dial-up, uma rede celular, e assim por diante.

[00028] Manifestações do sistema pode ser implementado em diversos ambientes operacionais, que incluem computadores pessoais, servidores, dispositivos PC de mão ou laptop, sistemas multiprocessadores, sistemas com microprocessador, eletroeletrônicos programáveis,câmeras digitais, PCs de rede, microcomputadores, computadores de unidade de processamento, ambientes de computação distribuídos que inclui qualquer um dos sistemas acima ou dispositivos, e assim por diante. Os sistemas de computador podem ser telefones celulares, assistentes digitais pessoais, telefones inteligentes, computadores pessoais, dispositivos eletrônicos programáveis, câmeras digitais, e assim por diante.

[00029] O sistema pode ser descrito no contexto geral de computa-dorexecutável de instruções, como os módulos do programa, executado por um ou mais computadores ou outros dispositivos. Geralmente, os módulos do programa incluem rotinas, programas, objetos, componentes, estruturas de dados, e assim por diante que executam tarefas específicas ou implementam determinados tipos de dados abstratos. Normalmente, a funcionalidade dos módulos do programa podem ser combinados ou distribuídos como desejado em várias modalidades.

[00030] Figura 2 é um diagrama de blocos que ilustra um ambiente operacional do sistema de transmissão de variação única usando a Microsoft Windows e IIS, em uma modalidade. O ambiente geralmente inclui um cliente fonte 210, uma rede de distribuição de conteúdo 240, e uma rede externa 270. O cliente de origem é a fonte da mídia ou evento ao vivo. O cliente de origem inclui uma fonte de mídia 220 e um ou mais codificadores 230. As origens da mídia 220 câmeras podem incluir cada uma com vários ângulos de câmera, microfones capturam de áudio, apresentações de slides, texto (como o de um serviço de closed caption), imagens e outros tipos de mídia. Os 230 codificadores codificam os dados da fonte de mídia 220 em um ou mais formatos de codificação em paralelo. Por exemplo, os codificadores 230 podem produzir mídias codificadas em uma variedade de taxas de bits.

[00031] A rede de distribuição de conteúdo 240 inclui um ou mais servidores ingerindo 250 e um ou mais servidores de origem 260. As ingestões 250 de servidores recebem mídia de codificados em cada um dos formatos de codificação 230 codificadores criam um manifesto descrevendo os meios de comunicação codificada. Os servidores de ingestão 250 podem criar e armazenar os blocos de mídia aqui mencionados, ou pode criar os blocos on the fly como eles são solicitados. Os servidores de ingestão 250 podem receber dados empurrados, como através de um POST HTTP, a partir do 230 codificadores, ou através de solicitação de dados de codificadores 230. Os 230 servidores de codificadores e ingestão 250 podem ser conectados em uma variedade de configurações redundantes. Por exemplo, cada codificador pode enviar dados codificados de mídia para cada um dos servidores de ingestão 250, ou somente a uma ingestão do servidor até que ocorra uma falha. Os servidores de origem 260 são os servidores que respondem às solicitações do cliente para blocos de mídia. A origem 260 servidores também pode ser configurada em uma variedade de configurações redundantes.

[00032] A rede externa inclui 270 servidores de borda 280 e outras Internet (ou rede) de infra-estrutura e clientes 290. Quando um cliente faz um pedido de um bloco de mídia, o cliente dirige a solicitação aos servidores de origem 260. Devido ao design de cache de rede, se um dos servidores de borda 280 contém os dados, então, que servidor de borda pode responder ao cliente sem repassar a solicitação. No entanto, se os dados não estão disponíveis no servidor de borda, então o servidor de borda encaminha o pedido a um dos servidores de origem 260. Da mesma forma, se um dos servidores de origem 260 recebe uma solicitação de dados que não está disponível, o servidor de origem pode solicitar os dados de um dos servidores de ingestão 250.

[00033] Figura 3 é um diagrama que ilustra o fluxo de processamento do sistema de adaptação de fluxo em um cliente para a reprodução de mídia, em uma modalidade. Início no bloco 310, o sistema seleciona uma codificação inicial da solicitação de mídia codificada a partir do servidor. Por exemplo, o sistema pode, inicialmente, selecionar uma menor taxa de bit disponível. O sistema pode enviar um pedido ao servidor para descobrir as taxas de bits disponíveis e outras codificações disponíveis. Continuando no bloco 320, o sistema solicitará e jogará um bloco especial da mídia, como descrito mais com referênciaà Figura 4. Continuando no bloco 330, o sistema determina um serviço de qualidade métrica baseada na parcela solicitada. Por exemplo, o bloco pode incluir metadados para tantos blocos adicionais que o servidor está armazenando, que o cliente pode usar para determinar o quão rápido o cliente está solicitando blocos em relação à rapidez com que o servidor está produzindo blocos. Este processo é descrito em mais detalhes aqui.

[00034] Continuando no bloco decisão 340, se o sistema determina que a corrente de QoS métrica é muito baixa e a conexão do cliente para o servidor não pode lidar com a codificação atual, o sistema continua no bloco 350, mais o sistema de circuitos bloqueiam 320 a lidar com o próximo bloco. Continuando no bloco 350, o sistema seleciona uma codificação diferente da mídia, onde o sistema seleciona uma codificação diferente solicitando dados de uma URL diferente para blocossubseqüentes do servidor. Por exemplo, o sistema poderá selecionar uma codificação que consome metade da largura de banda da codificação atual. Do mesmo modo, o sistema pode determinar que as métricas de QoS indiquem que o cliente pode lidar com uma codifica-ção de maior taxa de bits, e o cliente pode solicitar uma maior taxa de bits para blocos subseqüentes. Desta forma, o cliente ajusta a taxa de bits para cima e para baixo com base nas condições atuais.

[00035] Embora a Figura 3 ilustre a determinação QoS como ocorrendoapós cada bloco, os versados na técnica vão reconhecer que outras implementações de QoS são comuns, como esperando um número fixo de pacotes ou blocos (por exemplo, cada maço 10) para fazer uma QoS determinação. Depois bloco 350, o sistema de circuitos para bloquear 320 lida com o próximo bloco, se disponíveis ou completas se não mídias mais disponíveis (não mostrado).

[00036] Figura 4 é um diagrama que ilustra o fluxo de processamento do sistema de adaptação de fluxo para lidar com um bloco único de mídia, em uma modalidade. Continuando no bloco 410, o siste- ma envia um pedido de um bloco do cliente para um servidor através de uma rede com base na taxa de bits selecionada inicial. Por exemplo, o sistema poderá selecionar um determinado URL em que a solicitação de dados com base na codificação selecionada (por exemplo, http://server/a.isml/quality/bitrate). Continuando no bloco 420, o sistema recebe o bloco solicitado no cliente. O sistema pode receber o bloco do servidor ou de um cache entre o servidor e o cliente na rede. Continuando no bloco 430, o sistema analisa o bloco em uma parte de metadados e uma porção de dados de mídia. Por exemplo, cada bloco pode conter metadados que descreve a codificação do bloco e os dados de suportes adequados para a reprodução utilizando um codec e hardware apropriado.

[00037] Continuando no bloco 440, o sistema adiciona os metadados do bloco de um manifesto de mídia contínua que descreve informações sobre um elemento de mídia maior para que cada um dos blocos de suportes de dados pertencentes. Por exemplo, o sistema pode armazenar um manifesto na memória que contém os metadados de cada bloco de um arquivo de mídia. Continuando no bloco 450, o sistema reproduz os dados de mídia utilizando um codec identificado pelo bloco de metadados e hardware do cliente. Os dados de mídia podem incluir vídeo, áudio e outros tipos de dados que o sistema reproduz em hardware, incluindo um monitor, alto-falantes, e assim por diante. Alternativa ou cumulativamente, os dados podem incluir não dados audi-ovisuais (por exemplo, texto) que é consumido de alguma outra forma de reprodução, caso em que o sistema age sobre os dados com base no tipo de dados. Após o bloqueio 450, concluir estes passos.

[00038] Em algumas modalidades, o sistema adaptativo de fluxo fornece gravador de vídeo digital (DVR)-como funcionalidade para transmissões ao vivo de mídia. Em outras palavras, os usuários podem pausar uma transmissão ao vivo, procurando dentro do fluxo ao vivo, e assim por diante, sem adição de trabalho ou o rastreamento de estado para o servidor. Em uma transmissão ao vivo, há vários cenários como uma cena perdida, uma pausa, juntando-se o evento final e pretendendo assistir desde o início, e assim por diante que são habilitados pelo sistema que permite ao usuário reproduzir blocos em várias ordens e por diversas vezes. Com base no manifesto reunidos aqui descritos, o sistema oferece ao usuário controle sobre como eles assistem a uma transmissão ao vivo. Esses controles estão disponíveis hoje, com TV através de um DVR. O sistema adaptativo de fluxo inclui controles de cliente para responder às ações do usuário e gerenciar a reprodução de uma transmissão ao vivo em um modo de não-viver procurando a vários locais no manifesto. Além disso, o cliente pode alternar entre visualização ao vivo e não vivo durante a reprodução.

[00039] Em algumas modalidades, o sistema de fluxo adaptativo opera dentro de um navegador web plug-in. Por exemplo, o sistema pode ser incluído em uma aplicação Microsoft Silverlight. Microsoft Sil- verlight recebe referências em páginas web para aplicações contidas em recipientes chamados de arquivos XAP. Microsoft Silverlight extrai o arquivo XAP e invoca a aplicação. Microsoft Silverlight fornece aplicativos com um ambiente seguro em que modo seguro para executar de modo que o sistema do computador do usuário é protegido do código do aplicativo malicioso ou errado. Microsoft Silverlight oferece APIs que os aplicativos podem chamar a reprodução de mídia de uma forma que o sistema protege o usuário do computador e hardware a partir de ações de aplicativos potencialmente prejudiciais. Assim, Microsoft Silverlight e browser outros plug-ins podem fornecer toda a funcionalidade de um ambiente em que o sistema adaptativo de fluxo espera para operar.

[00040] Em algumas modalidades, o sistema de fluxo adaptativo recebe metadados de blocos mais tarde, em um bloco atual. Por exemplo, o servidor pode segurar um bloco particular que está pronto até algum número de blocos adicionais (por exemplo, dois blocos) está disponível. Então, o servidor pode enviar o bloco junto com informações de metadados sobre os blocos seguintes. O cliente pode usar essas informações para saber o que está por vir e se adaptar de forma adequada. Isso permite que o cliente ajuste inteligentemente a taxa de solicitação. Por exemplo, se um cliente solicita um pedaço e não tem qualquer informação sobre blocos mais tarde, então o cliente sabe que está solicitando dados muito rápidos. Se o cliente pede um bloco e recebe informações sobre muitos blocos mais tarde, então o cliente pode estar solicitando informações muito lentas. Assim, o cliente pode adaptar-se usando os metadados de antecedência como uma dica.

[00041] Em algumas modalidades, o sistema adaptativo de fluxo fornece um plug-in modelo de heurística para determinar qual codificação de mídia pode ser usado em um momento particular. Por exemplo, o sistema pode permitir que um administrador possa escolher entre várias estratégias para determinar a taxa de bits em que a solicitação de blocos de mídia com base em uma condição particular (por exemplo, largura de banda, redução ou perda de pacotes maiores). Além disso, os provedores de conteúdo podem incluir suas próprias heurísticas para determinar a codificação de uso, e pode fornecer a heurística como módulos de aplicação ou módulos de dependência de aplicativos em um pacote de aplicativos (por exemplo, a Microsoft Silverlight XAP) downloads de arquivos que o cliente jogue a mídia ao provedor de conteúdo.

[00042] Em algumas modalidades, a adaptação do sistema de fluxo de lojas o manifesto reuniu aqui descritos para uso posterior, como a reprodução de um dia após o evento ao vivo. Durante um evento ao vivo, o cliente tenha solicitado blocos de várias codificações com base nas condições da rede. O navegador do cliente também pode conter esses blocos no cache do navegador. Se o usuário solicita para reproduzir a mídia, mais tarde, pode ser mais eficiente para tentar reproduzir a mídia a partir do cache local, o que geralmente significa que o cliente solicita os blocos exatamente ao mesmo que foram originalmente jogados. Ao armazenar o manifesto com os metadados de cada bloco que foi efetivamente recebido, o cliente pode reproduzir a mídia voltando continuamente usando as mesmas codificações que foram solicitadas anteriormente. Isto pode permitir que o usuário assista a mídia em cenários, como um avião, onde a conectividade com o servidor de origem pode estar indisponível.

[00043] Em algumas modalidades, o sistema adaptativo de fluxo fornece a lógica para sincronizar os fluxos relacionados com meios de comunicação. Por exemplo, um evento ao vivo audiovisual pode incluir um ou mais fluxos de vídeo (por exemplo, ângulos de câmera) e um ou mais fluxos de áudio (por exemplo, línguas). Como o cliente faz o download do áudio e vídeo separadamente em blocos, o sistema reproduz o áudio e conteúdo de mídia de vídeo em sincronia, alinhando a informação de tempo associado a cada bloco, como descrito mais aqui com referência a sincronização do relógio. O sistema pode também sincronizar outros tipos de dados, tais como slides de uma apre-sentação de slides, imagens, texto, e assim por diante.

[00044] Em algumas modalidades, o sistema adaptativo de fluxo do lado do cliente fornece a lógica para mudar para fluxos de jogos diferentes da taxa (por exemplo, jogar truque) fornecidos pelo servidor. Por exemplo, o servidor pode incluir 2X, velocidades de 5X, 0.5X, e outros de reprodução. O cliente pode mudar para um fluxo de uma taxa diferente para fornecer a aparência para o usuário que a mídia é o avanço rápido (por exemplo, 2X) ou rebobinar (por exemplo, 0.5 X). Para mudar, o cliente simplesmente solicita um pedaço de mídia dife- rente, por exemplo, em um URL diferente. O cliente pode facilmente alternar entre jogando blocos no ritmo atual e jogar os blocos em um ritmo diferente, continuando a jogar os blocos particulares que são recebidos. Isso proporciona uma experiência transparente para o usuário final com latência pouco entre a solicitação do usuário e as mudanças na reprodução de mídia. Isto também economiza banda de rede como o cliente não faz o download, por exemplo, duas vezes os dados para reproduzir mídia duas vezes mais rápida, mas sim uma codificação de downloads tamanho reduzido dos meios de comunicação que é codificada a uma taxa acelerada.

[00045] Em algumas modalidades, o sistema de fluxo adaptativo recebe os marcadores de destaque nos metadados. Um destaque pode incluir qualquer segmento interessante de mídia, como um ponto durante um evento esportivo em que um jogador marcou um gol. O cliente pode desempenhar um carretel do destaque depois de um evento concluído, jogando os blocos dos meios de comunicação com associados marcadores de destaque. Se o cliente não receber o evento ao vivo, o cliente pode solicitar o manifesto para a mídia e em seguida, solicitar apenas os blocos correspondentes aos destaques. Se um usuário quer ver mais dos meios de comunicação antes e depois do destaque (por exemplo, como indicado pelo usuário o avanço rápido ou rebobinar), então o cliente pode solicitar blocos adicionais para jogar as parcelas solicitadas da mídia.

[00046] Em algumas modalidades, o sistema adaptativo de fluxo suporta publicidade em linha e outros não-audiovisuais dados (por exemplo, legendas, comentários, e assim por diante). Para um evento ao vivo, pode ser desconhecido no início do evento, quando os intervalos comerciais ocorrerão. Um coordenador do evento pode apertar um botão durante a produção quando é hora para um comercial, fazendo com que o sistema possa inserir um marcador de publicidade nos me tadados do fluxo de mídia. Quando o cliente recebe o marcador de publicidade, o cliente pode solicitar e receber blocos associados com uma propaganda previamente identificada. Por exemplo, o servidor pode fornecer uma lista de anúncios potenciais em um manifesto inicial. O anúncio pode ser fornecido em partes semelhantes para outras mídias, e não podem ser armazenados no mesmo servidor que fornece o evento ao vivo. Ao encontrar um marcador de propaganda, o cliente interrompe a reprodução do fluxo principal, recupera e exibe o anúncio, e depois retoma a reprodução do fluxo principal.

[00047] Em algumas modalidades, o sistema adaptativo de fluxo determina quais codificações estão disponíveis com base em um modelo de assinatura ou outro pagamento. Por exemplo, um provedor de conteúdo pode cobrar mais por uma versão de alta definição (HD) de um evento ao vivo do que uma versão de definição padrão (SD) do evento. Neste caso, o cliente pode habilitar ou desabilitar a mudança para taxas de bits especiais com base em saber se as condições do modelo de pagamento têm sido cumpridas (por exemplo, a conta do usuário é o atual). O provedor de conteúdo pode oferecer algumas codificações livres, como uma baixa taxa de bits ou destacar somente mídia, durante o carregamento para os outros.

[00048] O sistema adaptativo de fluxo pode solicitar e receber conteúdo de mídia em uma variedade de codificações. Em algumas modalidades, o sistema adaptativo de fluxo usa caixas de MP4 personalizadas. A Motion Picture Experts Group (MPEG) versão 4 padrão prevê caixas dentro do formato que pode conter dados personalizados. A extensão MP4 é o formato de arquivo comumente associado com esta versão do conteúdo. O sistema pode alavancar caixas para incluir os metadados personalizados e pedaços de conteúdo de mídia. Outros formatos de mídia fornecem a personalização de conteúdo semelhante dentro de um recipiente e pode ser usado pelo sistema.

[00049] Em algumas modalidades, o sistema adaptativo de fluxo está em conformidade com as diretrizes da Transferência de Estado Representacional (REST) estilo de arquitetura de software para sistemashipermídias distribuídos. Um conceito em REST é que um aplicativo pode interagir com um recurso, sabendo apenas o identificador do recurso (por exemplo, um URI) e a ação solicitada (por exemplo, recuperação), e sem saber se existem caches, proxies, gateways, firewalls, túneis, ou qualquer outra coisa entre a aplicação e o servidor realmentedetém a informação. Seguindo as diretrizes REST permitem que o sistema de benefícios da infra-estrutura de Internet existentes e técnicaspré-existentes de recursos de conservação, como cache. Alguns princípios exemplo RESTful que o sistema implementa em algumas modalidades incluem: cada URI identifica exatamente uma resposta, cada pontos URI para um recurso de servidor que é stateless e cacheable, e cada URI é intuitivo e utiliza os substantivos (os verbos são verbos HTTP). Em particular, o sistema pode evitar fazer pedidos usando seqüências de consulta e poderá usar as teclas substancialmenteúnicas para os horários de início que são solicitados via URLs. [00050] Pelo exposto, será apreciado que modalidades específicas do sistema adaptativo de fluxo foram aqui descritos para fins de ilustração, mas que várias modificações podem ser feitas sem se desviar do espírito e escopo da invenção. Assim, a invenção não é limitada, exceto como pelas reivindicações anexadas.

Claims (20)

1. Método para reproduzir sem problemas a mídia em um cliente, o método caracterizado pelo fato de que compreende as etapas de: enviar a partir do cliente um pedido de um bloco de mídia para um servidor através de uma rede, em que o bloco compreende uma porção uniforme da mídia disponível a partir do servidor para vários clientes e em que o pedido compreende um pedido de protocolo de transferência de hipertexto padrão (HTTP) que não inclui intervalos de bytes, de modo que uma resposta correspondente pode ser armazenada em cache por um servidor de cache da Internet comum que não armazena em cache intervalos de bytes; receber no cliente o bloco solicitado; analisar o bloco em uma porção de metadados e uma porção de dados de mídia: em que um cabeçalho de resposta HTTP recebido com o bloco solicitado não inclui um codec com o qual a porção de dados de mídia do bloco é codificada; acrescentar o bloco de metadados de um manifesto de mí-diacontínua que descreve informações sobre um elemento de mídia maior ao qual o bloco de mídia pertence; e reproduzir os dados de mídia utilizando um codec identificado pelo bloco de metadados e hardware do cliente, em que as etapas anteriores são executadas por pelo menos um processador.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o cliente receber o bloco pedido compreende receber o bloco de um cache de internet antes que o pedido chegue ao servidor e armazene o bloco em um cache do cliente.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que analisar ainda compreende identificar metadados que descreve a codificação do bloco e os dados de mídia adequados para a reprodução utilizando um codec e hardware apropriado.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o cliente armazena um manifesto na memória que contém os metadados de cada bloco de um arquivo de mídia.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a porção do bloco de metadados inclui informações sobre pelo menos um bloco subsequente disponível a partir do servidor.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende determinar uma taxa de bit de um bloco subsequente ao pedido, em que a taxa de bits determinada é baseada em uma contagem de informações sobre blocos subsequentes na porção de metadados do bloco.

7. Sistema de computador para processamento de mídia sem problemas a partir de um evento ao vivo, o sistema caracterizado pelo fato de que compreende: um processador e memória configurados para executar as instruções de software; um componente de pedido de bloco configurado para fazer pedidos de um cliente para blocos de mídia individuais de um servidor de origem, em que os blocos representam porções de um arquivo de mídia disponíveis individualmente a partir do servidor, e em que cada pedido compreende um pedido de protocolo de transferência de hipertextopadrão (HTTP) que não inclui intervalos de bytes, de modo que uma resposta correspondente pode ser armazenada em cache por um servidor de cache da Internet comum que não armazena em cache intervalos de bytes; um componente de análise do bloco configurado para interpretar um formato de cada bloco de mídia recebido pelo componente de pedido do bloco e separar os blocos em suas partes componentes, em que um cabeçalho de resposta HTTP recebido com cada pedaço solicitado não inclui um codec com o qual uma porção de dados de mídia do bloco é codificada; um componente de montagem manifestada configurada para construir um manifesto que descreve um elemento de mídia para o qual pertencem os blocos de conteúdo de mídia recebidos; um componente de reprodução de mídia configurado para reproduzir blocos de conteúdo de mídia recebidos usando hardware do cliente; um componente de monitorização QoS configurado para analisar um resultado de pacotes recebidos do servidor e adaptar solicitações do cliente com base em um conjunto de condições atuais da rede; e um componente de sincronização do relógio configurado para sincronizar os relógios do servidor e do cliente para que o servidor e o cliente possam identificar blocos especiais com base no tempo.

8. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de pedido de bloco solicita que os blocos utilizem pedidos HTTP GET.

9. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de pedido do bloco determina um usuário associado com o pedido e solicita que os blocos sejam base em um nível de subscrição do usuário.

10. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o cliente e o servidor de origem não tem uma conexão baseada no estado entre si.

11. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente pedido do bloco identifica cada bloco por um Uniforme Recurso Localizador (URL) que, individualmente, identifica o bloco.

12. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de análise do bloco separa o bloco em uma porção de cabeçalho contendo metadados e uma porção de dados que contenham conteúdo de mídia e em que o componente de análise do bloco fornece os metadados para o componente de montagem manifesto e o conteúdo de mídia para o componente de reprodução de mídia e se o bloco contém dados não audiovisuais analisar o bloco e consumir os dados não audiovisuais.

13. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de montagem de manifesto é ainda configurado para incluir nas informações de manifesto que descrevem um codec e uma taxa de bits usada para codificar cada bloco.

14. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de montagem de manifesto é ainda configurado para receber solicitações para reproduzir uma porção do elemento de mídia outro que não seja uma posição atual ao vivo com base no manifesto.

15. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de reprodução de mídia é ainda configurado para invocar um ou mais codecs para interpretar um recipiente no qual o conteúdo de mídia é transportado e para descomprimir o conteúdo de mídia a partir de um formato comprimido contido em cada bloco de mídia.

16. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de monitoramento de QoS é ainda configurado para mudar as taxas de bits dos blocos solicitados, solicitando blocos de uma URL de servidor diferente.

17. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de sincronização do relógio é ainda configurado para manter uma cadência de solicitações do cliente para o servidor para blocos de mídia subsequentes.

18. Dispositivo de armazenamento legível por computador, com um método caracterizado pelo fato de que compreende: selecionar uma codificação inicial na qual solicitar mídia codificada de um servidor, em que cada solicitação compreende uma solicitação HTTP (HTTP) que não inclui intervalos de bytes, de modo que uma resposta correspondente possa ser armazenada em cache por um servidor de cache da Internet comum que não intervalos de bytes de cache; receber um bloco de mídia específico do servidor, em que um cabeçalho de resposta HTTP recebido com o bloco solicitado não inclui um codec com o qual uma porção de dados de mídia do bloco é codificada; reproduzir o bloco de mídia recebido; determinar uma métrica de qualidade de serviço (QoS) com base no bloco recebido; e ao determinar que a métrica de QoS está muito baixa e a conexão do cliente com o servidor não pode lidar com a codificação atual, selecionar uma segunda codificação da mídia codificada, em que a segunda codificação da mídia codificada é codificada a uma taxa de bits mais baixa que a codificação inicial.

19. Dispositivo, de acordo com a reivindicação 18, caracterizado pelo fato de que a seleção de uma taxa de bits inicial compreende selecionar inicialmente uma menor taxa de bits disponível.

20. Dispositivo, de acordo com a reivindicação 18, caracterizado pelo fato de que ainda compreende mediante a determinação que a métrica de QoS é alta, selecionar uma terceira codificação da mídia codificada, em que a terceira codificação é codificada com uma taxa de bits mais alta que a codificação inicial.

Images