BR112017018939B1

BR112017018939B1 - Método para entregar uma resposta incompleta a uma solicitação de arquivo de mídia a partir de um servidor para um cliente, servidor, e, memória legível por computador

Info

Publication number: BR112017018939B1
Application number: BR112017018939-9A
Authority: BR
Inventors: Osama Lotfallah; Carlos Marcelo Dias Pazos; Charles Nung Lo; Nagaraju Naik; Thomas Stockhammer
Original assignee: Qualcomm Incorporated
Priority date: 2015-03-02
Filing date: 2016-02-29
Publication date: 2024-02-06
Also published as: JP6734291B2; BR112017018939A2; US10412138B2; CN114760281A; WO2016140918A1; KR102434958B1; CN107431699A; KR20170124551A; EP3266183A1; US20160261664A1; AU2016226411A1; JP2018514108A; EP3266183B1; AU2016226411B2

Abstract

sistemas, métodos e dispositivos das várias modalidades habilitam servidores http, possibilitam que os servidores http proporcionando segmentos para clientes dash de acordo com as várias modalidades, passem versões incompletas de segmentos em resposta às solicitações de segmento a partir dos clientes dash. as várias modalidades podem possibilitar que clientes, tais como os clientes dash, analisem versões incompletas de segmentos.

Description

PEDIDOS RELACIONADOS

[0001] O presente pedido reivindica prioridade para o Pedido de Patente Provisional dos Estados Unidos N° 62/126.842 intitulado “Indication for Partial Segment” depositado em 2 de março de 2015 e Pedido de Patente Provisional dos Estados Unidos N° 62/204.505 intitulado “Indication for Partial Segment” depositado em 13 de agosto de 2015. Os conteúdos integrais desses dois pedidos são aqui incorporados mediante referência.

ANTECEDENTES

[0002] Durante o transporte em rede de arquivos digitais, tais como fragmentos ou porções de vídeo que são enviadas em arquivos individuais denominados segmentos, vários eventos ou erros (por exemplo, perda de sintonia, erros de canal de rádio, etc.) podem ocorrer que resultam em arquivos apenas parciais sendo recebidos. Por exemplo, middleware de Serviço Multicast de Difusão de Multimídia Evoluído (eMBMS) atual em um dispositivo de computação pode apenas receber um segmento de Fluxo Contínuo Adaptativo Dinâmico (DASH) sobre Protocolo de Transferência de Hipertexto parcial mais propriamente do que o segmento inteiro. Uma aplicação e/ou um cliente proporcionando entradas para um codec, tal como um cliente DASH, pode ser habilitado, sob certas condições, para recuperar e proporcionar alguma porção de um arquivo para o codec embora o arquivo possa não ter sido recebido pela aplicação e/ou ciente em sua totalidade. Como as aplicações e/ou clientes atuais (por exemplo, clientes DASH atuais) não têm um mecanismo para indicar a capacidade atual do cliente e/ou da aplicação para receber segmentos parciais, os segmentos parciais podem não ser servidos à aplicação e/ou cliente. Por exemplo, middleware eMBMS atual em um dispositivo de computação pode descartar segmentos parciais, o que pode aumentar as interrupções de reprodução.

SUMÁRIO

[0003] Os sistemas, métodos e dispositivos das várias modalidades possibilitam que servidores de Protocolo de Transferência de Hipertexto (HTTP), tais como servidores HTTP proporcionando segmentos para clientes DASH de acordo com as várias modalidades, passem versões incompletas de segmentos em resposta às solicitações de segmento a partir dos clientes DASH. As várias modalidades podem possibilitar que os clientes, tais como clientes DASH, analisem versões incompletas de segmentos.

[0004] Algumas modalidades podem incluir o recebimento de uma solicitação de segmento em um servidor a partir de um cliente no qual a solicitação de segmento indica se o cliente é capaz de usar um segmento incompleto. O servidor pode determinar se um segmento completo associado com a solicitação de segmento está disponível no servidor. Em resposta à determinação de que o segmento inteiro associado com a solicitação de segmento não esteja disponível no servidor, o servidor pode determinar com base na solicitação de segmento, se o cliente é capaz de usar um segmento incompleto. Em resposta à determinação de que o cliente seja capaz de usar um segmento incompleto, o servidor pode enviar a partir do servidor para o cliente um segmento incompleto em uma mensagem de resposta incluindo uma indicação de que a mensagem de resposta inclui o segmento incompleto e uma indicação de uma ou mais posições de acesso para o segmento incompleto.

[0005] Algumas modalidades podem incluir o envio a partir de um servidor para um cliente de uma mensagem que inclui uma versão incompleta de um arquivo de mídia e um cabeçalho de extensão indicando um ou mais pontos de acesso para a versão incompleta do arquivo de mídia.

[0006] Modalidades adicionais incluem um servidor com um processador configurado com instruções executáveis por processador para realizar operações dos métodos resumidos acima. Modalidades adicionais incluem um servidor incluindo meios para realizar funções dos métodos resumidos acima. Modalidades adicionais incluem um meio de armazenamento legível por processador não transitório que tem nele armazenadas instruções executáveis por processador configuradas para fazer com que um processador de servidor realize operações dos métodos resumidos acima.

BREVE DESCRIÇÃO DOS DESENHOS

[0007] Os desenhos anexos, que são aqui incorporados e constituem parte desse relatório descritivo, ilustram modalidades exemplares da invenção, e em conjunto com a descrição geral fornecida acima e a descrição detalhada fornecida abaixo serve para explicar as características da invenção.

[0008] A Figura 1 é um diagrama de blocos de sistema de comunicação de uma rede adequada para uso com as várias modalidades.

[0009] A Figura 2A é um diagrama de blocos de sistema que ilustra a relação entre camadas de transporte e camadas de aplicação e/ou cliente em um dispositivo de computação de acordo com as várias modalidades.

[0010] A Figura 2B é um diagrama de blocos de sistema que ilustra a relação entre elementos de rede e camadas de aplicação e/ou cliente de dispositivo de computação de acordo com as várias modalidades.

[0011] A Figura 3 é um fluxograma de processo que ilustra um método da técnica anterior para manejo pelo servidor HTTP de solicitações de cliente para versões incompletas de segmentos.

[0012] A Figura 4 é um fluxograma de processo que ilustra um método de modalidade para manejo pelo servidor DASH de solicitações de cliente DASH para versões incompletas de segmentos.

[0013] A Figura 5 é um fluxograma de processo que ilustra outro método de modalidade para manejo pelo servidor DASH de solicitações de cliente DASH para versões incompletas de segmentos.

[0014] A Figura 6 é um fluxograma de processo que ilustra um terceiro método de modalidade para manejo pelo servidor DASH de solicitações de cliente DASH para versões incompletas de segmentos.

[0015] As Figuras, 7 e 8, são fluxogramas de chamada que ilustram interações entre um cliente DASH e servidor DASH de acordo com várias modalidades.

[0016] A Figura 9 é um fluxograma de processo que ilustra um quarto método de modalidade para manejo pelo servidor DASH de solicitações de cliente DASH para versões incompletas de segmentos.

[0017] As Figuras, 10 e 11, são fluxogramas de chamada que ilustram interações entre um cliente DASH e servidor DASH de acordo com várias modalidades.

[0018] A Figura 12 é um fluxograma de processo que ilustra um quinto método de modalidade para manejo pelo servidor DASH de solicitações de cliente DASH para versões incompletas de segmentos.

[0019] A Figura 13 é um fluxograma de chamada que ilustra interações entre um cliente DASH e servidor DASH de acordo com várias modalidades.

[0020] A Figura 14 é diagrama de blocos de dados de segmentos de um fluxo de mídia.

[0021] A Figura 15 é um fluxograma de processo que ilustra um método de modalidade para manejo pelo cliente DASH de versões incompletas de segmentos.

[0022] A Figura 16 é um diagrama de componentes de um dispositivo de computação exemplar adequado para uso com as várias modalidades.

[0023] A Figura 17 é um diagrama de componentes de um servidor exemplar adequado para uso com as várias modalidades.

DESCRIÇÃO DETALHADA

[0024] As várias modalidades serão descritas em detalhe com referência aos desenhos anexos. Sempre que possível, os mesmos números de referência serão usados por todos os desenhos para referência às mesmas partes ou partes semelhantes. Referências feitas aos exemplos e implementações específicas são para fins de ilustração, e não pretendem limitar o escopo da invenção ou das reivindicações.

[0025] As várias modalidades permitem que os servidores HTTP, tais como servidores DASH, proporcionem segmentos de arquivos de mídia DASH para clientes DASH de acordo com as várias modalidades, passem versões incompletas de segmentos, em resposta a pedidos de segmento dos clientes, tais como clientes DASH.

[0026] Como usado aqui, os termos “dispositivo móvel”, “dispositivo receptor”, e “dispositivo de computação” são utilizados indiscriminadamente para se referir a qualquer um ou todos os telefones celulares, smartphones, leitores de multimídia pessoais ou móveis, assistentes pessoais de dados (PDAs), computadores portáteis, computadores pessoais, computadores tablet, livros inteligentes, computadores palm-top, receptores de correio eletrônico sem fio, telefones celulares habilitados para Internet multimídia, controladores de jogos sem fio, TV por satélite ou cabo, conversores de sinais, aparelhos de reprodução de fluxo contínuo de mídia (tais como, ROKU ™ ou CHROMECAST ™ ou FIRE TV ™), televisores inteligentes, gravadores de vídeo digital (DVRs), e dispositivos eletrônicos pessoais semelhantes que incluem um processador programável e memória e circuitos para receber arquivos.

[0027] As várias modalidades são aqui descritas utilizando o termo “servidor” para se referir a qualquer dispositivo de computação capaz de funcionar como um servidor, tal como um servidor mestre de troca, servidor da Web, servidor de correio, servidor documento, servidor de conteúdo, ou qualquer outro tipo de servidor. Um servidor pode ser um dispositivo de computação dedicado ou um dispositivo de computação, incluindo um módulo de servidor (por exemplo, executar uma aplicação, que pode fazer com que o dispositivo de computação para operar como um servidor). Um módulo servidor (por exemplo, aplicação de servidor) pode ser um módulo de servidor função completa, ou um módulo de servidor secundário ou luz (por exemplo, luz ou aplicação de servidor secundário) que é configurado para fornecer serviços de sincronização entre as bases de dados dinâmicos em dispositivos receptores. Um servidor leve ou servidor secundário pode ser uma versão enxuta da funcionalidade de tipo de servidor que pode ser implementado em um dispositivo receptor permitindo assim funcionar como um servidor de Internet (por exemplo, um servidor de e-mail corporativo) apenas na medida necessária para fornecer a funcionalidade aqui descrita.

[0028] Tal como aqui utilizado, o termo “versão incompleta de um segmento” é utilizado para se referir a uma versão incompleta de um arquivo que tem em porções de dados ausentes e/ou corrompidas. Por exemplo, se um segmento inclui 1000 bytes indexados por 0-999 então bytes 0-888 daquele segmento são uma versão incompleta desse segmento, e bytes 500-999 é outra versão incompleta desse segmento, e bytes 0-200 juntamente com 300-999 bytes é outra versão incompleta desse segmento, ao passo que bytes 0-999 não são uma versão incompleta desse segmento.

[0029] No atual protocolo de transferência de hipertexto (HTTP) 1.1 definido na Internet Engineering Task Force proposta Request padrão for Comments (RFC) 2616, intitulado “Hypertext Transfer Protocol - HTTP/1.1”, publicado junho de 1999, disponível em http: // ferramentas. ietf.org/html/rfc2616, não há nenhum mecanismo para servidores para fornecer uma versão incompleta de um arquivo (por exemplo, arquivos que têm porções falta/corrompidos dados) para clientes em resposta a apresentar pedidos. No protocolo HTTP atual, um cliente pode gerar uma solicitação de arquivo, como um método “GET”, e enviar a solicitação de arquivo a um servidor. solicitações de arquivo podem ser pedidas para um arquivo associado a um URL/URI, e podem ser pedido de todo o conteúdo de dados de um arquivo associado a um URL/URI (por exemplo, usando uma solicitação GET que não especifica qualquer faixa de bytes e, portanto, solicita que o arquivo completo) ou podem ser pedidos de intervalos de bytes específicas de um arquivo associado com um URL/URI (por exemplo, utilizando um pedido GET parcial que especifica um faixa de bytes dentro do arquivo completo).

[0030] No protocolo HTTP atual, um servidor pode fornecer uma “resposta completa” ou uma mensagem de erro, em resposta à solicitação de arquivo de um cliente. O servidor HTTP não irá fornecer versões incompletas de um arquivo em resposta a solicitações de arquivo do cliente HTTP. Para solicitações GET que solicitam um arquivo completo, uma resposta completa do servidor HTTP é o arquivo completo, e uma versão incompleta de uma resposta arquivo é nada menos do que o arquivo completo (por exemplo, uma versão incompleta de um arquivo). Para solicitações GET parciais que especificam um faixa de bytes , uma resposta completa do servidor HTTP é a interseção entre o arquivo completo e o faixa de bytes solicitado, e uma versão incompleta de uma resposta faixa de bytes é nada menos do que a intersecção entre o arquivo completo e o intervalo solicitado byte (por exemplo, uma versão incompleta de um faixa de bytes).

[0031] Em particular, o protocolo HTTP atual, quando um servidor recebe uma solicitação de arquivo, o servidor pode determinar se o arquivo correspondente à solicitação de arquivo está totalmente disponível. Como exemplo, o servidor pode determinar se o arquivo correspondente ao pedido de arquivo é incompleto e/ou danificados, tais como porções de dados ausentes e/ou incluindo uma indicação de que o arquivo é incompleto e/ou corrompido. Como exemplo, o servidor pode determinar se o arquivo correspondente ao pedido de arquivo é incompleto e/ou corrompido por determinar se a descodificação FEC foi bem ou mal sucedida. Como outro exemplo, o servidor pode determinar se o arquivo correspondente ao pedido de arquivo é incompleto e/ou corrompidos pela detecção de uma diferença de um valor de uma soma de controlo recebida, tais como o resumo MD5, e uma soma de verificação calculada por um receptor de FLUTE. Os arquivos que não estejam incompletos e/ou corrompidos podem ser determinados pelo servidor como estando totalmente disponíveis e podem ser enviados para o cliente em uma “resposta completa”, que inclui o arquivo solicitado. No protocolo HTTP atual, ao identificar que o arquivo solicitado não está totalmente disponível (ou seja, apenas uma versão incompleta do arquivo está disponível que tem faltando porções dados/corrompidos), o servidor simplesmente retorna uma mensagem com um código de status de erro, tais como uma mensagem com um “Not Found” código de status 404. Assim, no protocolo HTTP atual, a versão incompleta de um arquivo não é enviada para o cliente solicitante; isto é, uma “resposta incompleta” a um pedido de um arquivo não é suportado.

[0032] Como mencionado acima, o protocolo HTTP atual igualmente fornece solicitações GET parciais, que especificam um faixa de bytes de um arquivo pedido, e a resposta completa para solicitações GET parciais é a intersecção entre o arquivo completo e o faixa de bytes solicitado. Por exemplo, no HTTP atual quando um cliente HTTP envia um pedido GET parcial para um faixa de bytes que se estende para além do fim do processo completo, a resposta completa que um servidor HTTP pode fornecer uma porção sequencial de bytes a partir do primeiro byte o faixa de bytes solicitado ao último byte do arquivo completo. Assim, em um exemplo em que o faixa de bytes é solicitado 0-100, mas o processo completo tem apenas bytes 0-88, a resposta total é menos do que o faixa de bytes requerida (em particular, os bytes 0-88), mas é considerada uma “resposta completa”, no entanto, e pode ser enviada pelo servidor HTTP.

[0033] No entanto, no protocolo HTTP atual, quando um cliente HTTP envia um pedido GET parcial e alguns dos bytes dentro do intervalo especificado são bytes ausentes/corrompido (ou seja, apenas uma versão incompleta do faixa de bytes solicitado está disponível no servidor HTTP), o servidor HTTP pode não fornecer qualquer parte dos bytes solicitados para o cliente, e em vez disso envia ao cliente uma mensagem com um status de erro código. Assim, em um exemplo no qual um faixa de bytes solicitado é 0-99, mas apenas bytes 0-74 e 126-150 estão disponíveis porque bytes 75-125 estão ausentes ou corrompidos, o servidor HTTP atual não vai enviar uma versão incompleta do resposta faixa de bytes consistindo de bytes 0-74 para o cliente requerente. Assim, no protocolo HTTP atual, a versão incompleta de um pedido de faixa de bytes não é enviada para o cliente solicitante. Isso ocorre porque uma “resposta incompleta” a um pedido de um faixa de bytes de um arquivo não é suportada.

[0034] Uma vez que o protocolo HTTP como definido atualmente não passa respostas incompletas para um cliente, a funcionalidade de clientes e/ou aplicações que estão habilitadas para recuperar e utilizar respostas incompletas podem ser reduzidas porque os clientes e/ou aplicações podem nunca receber respostas incompletas. Assim, pode ser útil permitir que servidores HTTP entreguem aos clientes pelo menos uma parte das versões incompletas de arquivos ou versões incompletas de intervalos de bytes de arquivos que estão disponíveis no servidor. O fornecimento de pelo menos uma parte da versão incompleta de uma faixa de arquivo ou byte pode permitir que dispositivos de cliente executando uma aplicação e/ou cliente (por exemplo, como um telefone inteligente executando um cliente DASH) para processar o conteúdo, tal como a reprodução pelo menos uma parte dos meios de comunicação na versão incompleta de um segmento ou byte faixa de um segmento, o que pode melhorar a experiência de reprodução de media usuário final.

[0035] As várias modalidades abordam esta lacuna no protocolo HTTP atual, permitindo que servidores HTTP, tais como servidores DASH proporcionem segmentos de clientes DASH, para passar versões incompletas de segmentos, em resposta a pedidos de segmento dos clientes DASH. Em uma modalidade, um cliente DASH pode gerar um pedido de segmento incluindo uma versão incompleta de uma indicação capaz segmento. Esse pedido de segmento pode ser uma mensagem de solicitação, tal como uma operação de “GET” (isto é, método), incluindo um campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento (por exemplo, um segmento incompleto). Em uma modalidade, o campo de cabeçalho pode ser um campo de cabeçalho aceitar descrito na RFC 7231. Por exemplo, uma operação de GET com a aceitar indicação campo do cabeçalho “aplicação/3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento. Em uma modalidade, o campo de cabeçalho pode ser um campo de cabeçalho de preferência descrito na RFC 7240. Por exemplo, uma operação de GET com a indicação preferem campo do cabeçalho “retorno = 3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento. Em uma modalidade, o pedido do segmento com o campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento pode ser enviada em um pedido inicial de um segmento. Noutra modalidade, o pedido do segmento com o campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento pode ser enviado em resposta a uma mensagem de erro inicial, tal como uma mensagem de erro, incluindo um código de estado 404 “não encontrado”, retornado de um servidor. Em resposta a receber a mensagem de erro inicial, o cliente pode voltar a pedido do segmento anteriormente solicitados, desta vez, incluindo o campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento. Em uma outra modalidade, o pedido de segmento com o campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento pode ser enviado em resposta a uma indicação de faixa de bytes devolvido a partir de um servidor, que inclui uma porção importante do segmento que permite meios de posicionamento amostras (tal como a caixa “trun” em ISOBMFF). Em resposta ao recebimento da indicação de faixa de bytes inicial, o cliente pode pedir porções subsequentes de faixa de bytes do segmento, desta vez, incluindo o campo de cabeçalho indicando que o cliente é capaz de usar uma versão incompleta de um segmento.

[0036] Em uma modalidade, um servidor DASH pode gerar e enviar uma mensagem de resposta inicial incluindo uma indicação de que uma versão incompleta do segmento solicitado está disponível e que os intervalos de bytes do segmento estão disponíveis. Em uma modalidade, a mensagem de resposta pode ser uma mensagem que inclui uma extensão de cabeçalho indica que uma versão incompleta do segmento pedido estiver disponível e a intervalos de bytes disponíveis. Por exemplo, a resposta inicial pode ser uma mensagem de erro inclui um código de status 404 e um cabeçalho de extensão “X - Faixas Disponíveis: bytes ab, cd,...”. Como outro exemplo, a resposta inicial pode ser uma mensagem de conteúdo parcial, incluindo um código de status 206 e extensão cabeçalho “X - Faixas Disponíveis: bytes ab, cd,...”. Em uma modalidade, a mensagem de resposta pode ser uma mensagem de redirecionamento, tal como uma mensagem de série 300, incluindo um corpo de entidade indicando que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes que estão disponíveis, tais como “Tipo Content = 3GPP-parcial de bytes-faixas”.

[0037] Em resposta ao recebimento da mensagem de resposta inicial incluindo uma indicação de que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes do segmento estão disponíveis a partir do servidor DASH, o cliente DASH pode voltar a solicitar o segmento anteriormente solicitado, desta vez incluindo uma indicação de um intervalo de pedido parcial bytes correspondente às porções indicado como disponível pelo servidor DASH.

[0038] Em uma modalidade, um servidor DASH pode gerar e enviar uma mensagem de resposta incluindo uma indicação da posição de acesso para um cliente DASH capaz de usar uma versão incompleta de um arquivo. Uma indicação de posição de acesso pode ser uma posição de indicação de um byte (ou outro tamanho de dados) no arquivo solicitado no qual o cliente DASH pode acessar a versão incompleta do arquivo e começar a analisar a versão incompleta do arquivo para identificar pontos de acesso aleatório (por exemplo, jogos de Pontos de Acesso (PAE) tipagem de amostras de 1 ou 2) ou de sincronismo que podem ser utilizadas para decodificar e/ou tornar a versão incompleta do arquivo. Indicações de posição de acesso podem ser determinadas e indicadas em uma base por arquivo e/ou em uma base por faixa de bytes disponíveis. Para um segmento DASH, por exemplo, uma ou mais posições de acesso pode ser determinada e está associado ao segmento DASH, tal como em uma Tabela de Entrega de arquivos (FDT) descrevendo os segmentos de uma corrente de media DASH. Por exemplo, os pontos de acesso podem ser indicados na FDT no campo “IndependentUnitPositions”, indicando um ou mais posições espaciais bytes separados no segmento DASH no qual o cliente DASH pode aceder ao segmento.

[0039] Por exemplo, em resposta ao recebimento de um cliente DASH um pedido de uma versão incompleta de um segmento DASH, o servidor DASH pode enviar sinais de uma ou mais posições de acesso para o segmento DASH com a versão incompleta do segmento DASH. Como outro exemplo, quando uma versão incompleta de um arquivo está disponível no servidor DASH, o servidor DASH pode determinar uma ou mais posições de acesso para cada faixa de bytes do arquivo que está disponível. Desta forma, o servidor DASH pode indicar uma ou mais posições de acesso para uma primeira faixa de bytes (por exemplo, faixa de bytes ab) da versão incompleta de um segmento DASH e um ou mais de acesso posições para uma faixa segundo byte (por exemplo, faixa de bytes cd) da versão incompleta do segmento DASH.

[0040] Nas várias modalidades, uma posição de acesso pode ser indicada em uma extensão de cabeçalho, em uma mensagem de resposta enviada pelo servidor DASH. A mensagem de resposta pode indicar que a resposta inclui uma versão incompleta de um segmento DASH solicitado e indicar a posição de acesso para a versão incompleta. Por exemplo, a resposta pode incluir a campos de extensão de cabeçalho “3GPP-acesso-posição”, indicando uma ou mais posições de byte no segmento DASH no qual o cliente DASH pode aceder ao segmento, bem como incluindo “aplicação/3GPP-parcial”, tal como Content-Type indicando a resposta inclui uma versão incompleta do segmento DASH solicitado.

[0041] Em uma modalidade, em resposta à recepção de uma resposta incluindo uma versão incompleta de um segmento e uma indicação da posição de acesso, um cliente DASH pode determinar se uma porção inicial do segmento é recebido. Uma porção inicial do segmento pode ser um faixa de bytes no início de um segmento dedicado a indicando inicialização, indexação, temporização, e/ou informação de sincronização para o segmento. Em resposta à determinação de que a porção inicial do segmento é recebida, o cliente DASH pode usar o momento e/ou informação de sincronização na porção inicial para analisar as outras porções recebidas da versão incompleta do segmento. Em resposta à determinação de que a porção inicial do segmento não foi recebida, o cliente DASH pode determinar se o byte correspondente à posição de acesso foi recebido. Em resposta à determinação que o byte correspondente para a posição de acesso para o segmento foi recebido, o cliente DASH pode começar a analisar a versão incompleta do segmento na posição de acesso para identificar os pontos de acesso aleatório (por exemplo, pontos de fluxo de acesso (PAE) do tipo 1 ou 2) ou amostras de sincronização que pode ser usado para decodificar e/ou tornar a versão incompleta do segmento. Em resposta à determinação que o byte correspondente para a posição de acesso para o segmento não foi recebido, o cliente DASH pode pedir o segmento seguinte na representação.

[0042] Em uma modalidade, um servidor DASH pode gerar e enviar uma mensagem de erro em resposta a um cliente DASH capaz de usar uma versão incompleta de um arquivo solicitando um arquivo para o qual haja bytes disponíveis no servidor DASH. Por exemplo, o servidor DASH pode enviar uma mensagem de erro inclui um código de status 416 “Intervalo solicitado não satisfatório” quando há bytes para um segmento DASH ou byte intervalo solicitado de um segmento DASH estão disponíveis no servidor DASH. A mensagem de erro pode indicar ainda o tipo de conteúdo proporcionado no exemplo FDT para o segmento DASH, a localização conteúdo fornecido na FDT para o segmento DASH, e a faixa de conteúdo indicado como “bytes */conteúdo - comprimento” com base no comprimento de conteúdo indicado na FDT para o segmento DASH. Ao receber uma mensagem de erro inclui um código de status 416 “Intervalo solicitado não satisfatório”, o cliente DASH pode distinguir entre pedidos de segmentos inválidos (por exemplo, solicitações resultando em mensagens de erro com um código de status 404 “Não Encontradas”) e os pedidos de segmentos que foram perdidos na transmissão (por exemplo, segmentos indicado na FDT, mas sem bytes recebidos, resultando em mensagens de erro com um código de status 416 “Intervalo solicitado não satisfatório”). Em uma modalidade, o cliente DASH pode esconder os perdidos no segmento de transmissão indicado pela mensagem de erro com o código de estado 416 e continuar a operação normal, solicitando o segmento seguinte na representação.

[0043] Vários exemplos de diferentes aplicações/clientes, middleware, cronogramas de disponibilidade de segmento, tecnologias de rádio, e protocolos de transporte são aqui discutidos, especificamente clientes DASH, eMBMS e HTTP. As discussões de clientes DASH, eMBMS, e HTTP são fornecidas apenas como exemplos para ilustrar melhor os aspectos das várias modalidades, e não se destinam a limitar as várias modalidades de forma alguma. Outras aplicações/clientes, middleware, tecnologias de rádio, e protocolos de transporte podem ser usados com as diversas modalidades, e outras aplicações/clientes, middleware, tecnologias de rádio, e protocolos de transporte podem ser substituídos nos vários exemplos sem se afastar do espírito ou âmbito da invenção.

[0044] A figura 1 ilustra um sistema de rede celular 100 apropriado para uso com as várias modalidades. O sistema de rede celular 100 pode incluir vários dispositivos, tais como um dispositivo de computação 102, uma ou mais torres celulares ou estações de base 104, e os servidores 108 e 112 ligados à Internet 110. O dispositivo de computação 102 podem trocar dados por meio de uma ou mais conexões celulares 106, incluindo Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), Personal Communication Service (PCS), Third Generation (3G), Fourth Generation (4G), Long Term Evolution (LTE), ou qualquer outro tipo de ligação, com a torre ou de base celular 104. A torre celular ou estação base 104 pode estar em comunicação com um roteador que pode ligar-se à Internet 110. Desse modo, através das ligações da torre celular ou estação base 104, e/ou da Internet 110, os dados podem ser trocados entre o dispositivo de computação 102 e o servidor (es) 108 e 112. Em uma modalidade, o servidor 108 pode ser um conteúdo servidor do provedor ou codificador (por exemplo, um servidor de conteúdo) fornecendo segmentos para a saída através de um cliente DASH. Em uma modalidade, o servidor 112 pode ser um servidor Broadcast Center Serviço Multimedia (BMSC) que podem receber a saída de segmentos do codificador e controlar transmissão pelo ar (OTA) dos segmentos para o dispositivo de computação 102. Claro que, enquanto características de dispositivos receptores aqui descritos podem ser descritas com referência às transmissões OTA, estas características podem ser usadas em ligação com transmissões de fio, transmissões sem fios, ou uma combinação de transmissões com e sem fios. Assim, a transmissão OTA não é necessária.

[0045] A figura 2A ilustra uma relação de modalidade entre camadas de transporte e de aplicação e/ou camadas de cliente em um dispositivo de computação. Em uma modalidade, os arquivos podem ser recebidos no dispositivo de computação através da Internet Protocol/User Datagram Protocol (IP/UDP) da camada de transporte 202. Como um exemplo, arquivos de difusão enviados a partir do servidor 112 para o dispositivo de computação 102 através da Internet 110, como discutido acima com referência à figura 1, pode ser recebido no dispositivo de computação 102 na camada/transporte UDP IP 202. Em uma modalidade, os arquivos podem ser segmentos de um arquivo de mídia enviado através da Internet.

[0046] A camada de transporte IP/UDP 202 pode passar os arquivos recebidos para a camada Entrega de Arquivo através de Transporte Unidirecional (FLUTE) 204. Em uma modalidade, a camada de FLUTE 204 pode ser uma aplicação activado para utilizar o protocolo FLUTE para passar arquivos a partir da camada/transporte UDP IP 202 de aplicações e/ou clientes, tais como um cliente DASH 210. Em uma modalidade, a camada FLUTE 204 podem aplicar a correção de erro para os arquivos recebidos, tais como a correção antecipada de erros (FEC). Em uma modalidade, a camada FLUTE 204 pode receber indicações das aplicações e/ou clientes, tais como um cliente DASH 210, o que pode indicar se as aplicações e/ou clientes estão habilitados a utilizar versões incompletas de segmentos. Como exemplo, um pedido de arquivo do cliente DASH 210 pode indicar que o cliente DASH 210 está habilitado a utilizar versões incompletas de arquivos. A camada FLUTE 204 pode analisar os arquivos recebidos e passar os arquivos para o servidor de HTTP do lado do dispositivo, tais como um servidor 206. O DASH eMBMS middleware 207 executado no dispositivo de computador pode incluir uma ou mais do servidor DASH lado do dispositivo 206, camada FLUTE 204, e/ou de transporte IP/UDP camada 202. Em uma modalidade, o servidor DASH lado do dispositivo 206 pode ser uma aplicação residente servidor HTTP no dispositivo de computação com o seu próprio espaço de memória atribuída (por exemplo, memória cache) no dispositivo de computação. Em uma modalidade, o cliente pode pedir DASH 210 e/ou receber arquivos a partir do servidor DASH lado do dispositivo 206 e pode passar os arquivos para um codec 212 para eventual prestação do conteúdo (por exemplo, reproduzir o conteúdo) pelo dispositivo de computação. Em uma modalidade, um cliente DASH 210 pode ser activado para utilizar versões incompletas de arquivos na prestação do conteúdo. Em outra modalidade, um cliente DASH 210 pode ser habilitado para reparar versões incompletas de arquivos antes de processar o conteúdo.

[0047] A figura 2B ilustra uma relação de modalidade entre elementos da rede e aplicação de dispositivo de computação e/ou camadas de cliente. Como um exemplo, os arquivos (por exemplo, segmentos de uma corrente de saída de meios DASH por um codificador) pode ser enviado a partir do servidor de conteúdo 108 (por exemplo, um servidor DASH) para o servidor 112 (por exemplo, um servidor BMSC com um remetente FLUTE). Além disso, o servidor de conteúdo 108 pode determinar uma ou mais posições de acesso para os arquivos (por exemplo, segmentos do fluxo de mídia DASH) e pode enviar indicações das posições de acesso às posições de acesso ao servidor 112. podem ser indicações de uma posição de byte na arquivo solicitado no qual um cliente pode acessar uma versão incompleta do arquivo e começar a analisar a versão incompleta do arquivo para identificar pontos de acesso aleatório (por exemplo, pontos de fluxo de acesso (SAPs) tipo 1 ou 2) ou sincronização de amostras que podem ser usados para decodificar e/ou tornar a versão incompleta do arquivo. Enquanto que a figura 2B ilustra as posições de acesso a ser fornecida pelo servidor 108, posições de acesso podem ser determinadas e/ou indicado por qualquer elemento no sistema de comunicação, tal como o servidor 112, o middleware eMBMS 207, etc. O servidor 112 pode empacotar os arquivos mediante transmissão para o dispositivo de computação 102 e preparar uma tabela de envio de arquivos (FDT) de acordo com o protocolo FLUTE. Em uma modalidade, o FDT pode incluir indicações das posições de acesso. Por exemplo, o FDT pode incluir o atributo “IndependentUnitPositions”, indicando um ou mais posições de byte separados por espaços nos segmentos DASH em que o cliente pode aceder DASH os segmentos.

[0048] O servidor 112 pode transmitir o FDT incluindo as indicações das posições de acesso e os arquivos e os pacotes para o dispositivo de computação 102. Os pacotes podem ou não podem ser perdidas na transmissão a partir do servidor 112 para o middleware eMBMS 207 do dispositivo de computação 102. Uma versão completa de um arquivo pode ser montada pelo middleware eMBMS 207 e disponibilizado para o cliente DASH 210 quando os pacotes para um arquivo não são perdidas. Uma versão incompleta de um arquivo pode ser montada pelo middleware eMBMS 207 e disponibilizado para o cliente DASH 210 quando menos do que todos os pacotes para um arquivo são perdidos, ou quando menos do que todos os pacotes para um arquivo são perdidas e não recuperáveis pela aplicação de correção de erros. Nenhuma versão de um arquivo pode ser montada pelo middleware eMBMS 207 quando todos os pacotes para um arquivo são perdidas e não recuperáveis através da aplicação de correção de erros. O middleware eMBMS 207 pode identificar se uma versão completa, versão incompleta e/ou qualquer versão de um arquivo foi recebida com base em indicações de arquivo na FDT recebido.

[0049] O cliente DASH 210 pode enviar uma solicitação de arquivo (por exemplo, uma operação de HTTP GET), indicando que o cliente DASH 210 está habilitado a utilizar versões incompletas de arquivos (por exemplo, uma operação de GET com a indicação de campo de cabeçalho Preferir “retorne = 3GPP - partial”, uma operação GET com a indicação de campo de cabeçalho Aceitar “aplicação/3GPP- parcial”, etc.). O middleware eMBMS 207 (por exemplo, através do servidor DASH pelo lado do dispositivo 206) pode enviar uma resposta HTTP para o cliente DASH 210 em resposta à solicitação de arquivo indicando que o cliente DASH 210 está habilitado a utilizar versões incompletas de arquivos. Como exemplo, o servidor DASH 206 pode enviar uma resposta 200 OK com o arquivo solicitado completa quando uma versão completa do arquivo está disponível. Como outro exemplo, o servidor DASH 206 pode enviar uma resposta 200 OK com a versão incompleta do arquivo e uma indicação da posição de acesso associado a esse arquivo indicado na FDT recebido quando uma versão incompleta do arquivo está disponível. Como outro exemplo, o servidor DASH 206 pode enviar uma resposta 416 “Faixa Solicitada não Satisfatória” sem carga útil quando nenhuma parte do arquivo estiver disponível.

[0050] Embora que as figuras 2A e 2B ilustrem e sejam discutidos em termos de um cliente DASH 210 e um servidor DASH 206 executando em um ou mais processadores de um dispositivo de computação, trocas de servidor de dispositivo interno/cliente são meramente um exemplo de trocas servidor/cliente, e as várias modalidades aqui descrito pode ser igualmente aplicável a qualquer tipo de troca servidor/cliente. Por exemplo, o servidor DASH 206 e o cliente DASH 210 podem ser dispositivos separados que se comunicam através de uma rede externa, como a Internet.

[0051] A figura 3 ilustra o método 300 da técnica anterior empregado pelos servidores HTTP atuais para o manuseamento de pedidos do cliente para versões incompletas de segmentos. No bloco 302, o cliente pode gerar um pedido de segmento. Um pedido de segmento é uma mensagem, tal como uma operação “GET” (isto é, método) solicitando um segmento. O pedido de segmento inclui a URL/URI do segmento solicitado. No protocolo HTTP atual, os pedidos de segmentos também podem ser realizados usando a operação de “GET parcial”, que pode incluir um pedido para uma porção de um segmento no URL/URI, incluindo um ou mais intervalos de byte representando um subconjunto do total do segmento associado com a URL/URI. No entanto, no protocolo HTTP atual, o pedido de segmento não inclui uma indicação de que o cliente está habilitado a utilizar uma versão incompleta de um segmento, no que diz respeito quer ao recurso integral solicitado através do “GET”, ou um recurso parcial como indicado pela “GET parcial.” Com efeito, os pedidos de segmentos HTTP atuais são efetivamente “tudo ou nada” pedidos indicando que o cliente só pode usar todo o segmento ou todo o subconjunto do segmento que está sendo solicitado.

[0052] No bloco 306, o servidor HTTP recebe o pedido de segmento enviado pelo cliente no bloco 304. No bloco de determinação 308, o servidor de HTTP determina se o segmento solicitado completo está disponível. O servidor HTTP pode determinar se o segmento requisitado completo, ou um subconjunto inteiro está disponível observando a URL/URI associada à solicitação de segmento e determinar se no segmento no URL/URI faltam dados e/ou estão danificados de alguma forma. No protocolo HTTP atual, somente se no segmento ou no subconjunto inteiro procurado não estiver faltando dados e/ou não estiverem corrompidos é que o segmento ou o subconjunto inteiro procurado é determinado como sendo segmentos completos e considerados elegíveis a serem retornados.

[0053] Em resposta à determinação de que o segmento solicitado completo esteja disponível (ou seja, o bloco de determinação 308 = “Sim”), o servidor de HTTP envia uma resposta incluindo o segmento solicitada no bloco 310, e no bloco 312 o cliente recebe a resposta, incluindo o segmento. A resposta pode incluir um código de status indicando que todo o segmento solicitado foi recuperado com sucesso, como 200 “OK”.

[0054] Em resposta à determinação de que o segmento solicitado completo não esteja disponível (ou seja, o bloco de determinação 308 = “não”), o servidor de HTTP envia uma mensagem de erro, sem qualquer porção do segmento solicitada no bloco 314, e o cliente recebe o mensagem de erro no bloco 316. A mensagem de erro pode incluir um código de status, como 404 “Não Encontrado”. A desvantagem do método HTTP atual 300 é que os clientes nunca recebem as versões incompletas de segmentos disponíveis no servidor. Assim, em sistemas de HTTP atuais, os clientes que estão habilitados a usar versões incompletas de segmentos não pode melhorar a experiência do usuário final reprodução de mídia, jogando versões incompletas de segmentos porque eles não recebem versões incompletas de segmentos dos servidores HTTP.

[0055] As várias modalidades melhoram a experiência de reprodução de mídia de usuário final, permitindo que servidores DASH proporcionem versões incompletas de segmentos, em resposta aos pedidos dos clientes. As figuras 4-15 ilustram métodos de modalidade para manejo pelo servidor de pedidos do cliente para versões incompletas de segmentos. Enquanto discutido em termos de dispositivos de cliente DASH e servidores DASH as operações dos métodos de realização ilustrado nas figuras 4-15 pode ser realizada por quaisquer dois dispositivos e/ou aplicações que operam em uma relação cliente/servidor.

[0056] A figura 4 ilustra um método de modalidade 400 para a manejo de servidor DASH de pedidos do cliente para DASH versões incompletas do segmento. Em uma modalidade, as operações de método 400 pode ser realizado por um servidor DASH em comunicação com um cliente DASH para entregar uma resposta incompleta a um pedido de arquivo de mídia a partir do servidor DASH para o cliente DASH. No bloco 402, o cliente DASH pode gerar um pedido de segmento incluindo uma versão incompleta de uma indicação capaz segmento. Em uma modalidade, o pedido de segmento, incluindo uma versão incompleta de uma indicação capaz segmento, pode ser uma operação de “GET” (isto é, método), incluindo um campo de cabeçalho indica que o cliente DASH é capaz de usar uma versão incompleta de um segmento (por exemplo, um segmento incompleto). Em uma modalidade, o campo de cabeçalho pode ser um campo de cabeçalho aceitar descrito na RFC 7231. Por exemplo, uma operação de GET com a aceitar indicação campo do cabeçalho “aplicação/3GPP- parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta a o pedido de segmento. Em uma modalidade, o campo de cabeçalho pode ser um campo de cabeçalho de preferência descrito na RFC 7240. Por exemplo, uma operação de GET com a indicação preferem campo do cabeçalho “retorno = 3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta a o pedido de segmento.

[0057] No bloco 404 o cliente DASH pode enviar o pedido de segmento para o servidor DASH, e no bloco 406 o servidor DASH pode receber o pedido de segmento.

[0058] No bloco de determinação 408, o servidor DASH pode determinar se o segmento solicitado completo está disponível. Em uma modalidade, o servidor DASH pode determinar se o arquivo solicitado completo está disponível por olhar para a URL/URI associado à solicitação de segmento e determinar se o segmento na URL/URI está faltando dados e/ou está danificado de alguma forma. Esses segmentos sem porções de dados ausentes e/ou não incluindo de dados corrompidos podem ser determinados como sendo segmentos completos. Esses segmentos de dados ausentes e/ou incluindo dados corrompidos podem ser determinados como sendo versões incompletas de segmentos.

[0059] Em resposta à determinação de que o segmento solicitado completo está disponível (ou seja, o bloco de determinação 408 = “Sim”), o servidor DASH pode enviar uma resposta incluindo o segmento solicitado completo no bloco 410, e o cliente DASH pode receber a resposta incluindo o segmento solicitado completo no bloco 412. a resposta pode incluir um código de status indicando que todo o segmento solicitado foi recuperado com sucesso, como 200 “OK”.

[0060] Em resposta à determinação que o segmento solicitado completo não está disponível (ou seja, o bloco de determinação 408 = “não”), o servidor DASH pode determinar se o cliente DASH indicou que é capaz de utilizar uma versão incompleta de um segmento em bloco de determinação 414. Em uma modalidade, o servidor DASH pode determinar o cliente DASH é capaz de usar uma versão incompleta de um segmento com base, pelo menos em parte sobre o campo de segmento de cabeçalho pedido indicando que o cliente DASH é capaz de usar uma versão incompleta um segmento.

[0061] Em resposta à determinação que o cliente DASH não é capaz de utilizar uma versão incompleta de um segmento (isto é, bloco de determinação 414 = “não”), o servidor DASH pode enviar uma mensagem de erro, sem qualquer porção do segmento solicitados a o cliente DASH no bloco 416, e o cliente DASH pode receber a mensagem de erro no bloco 424. Em uma modalidade, a mensagem de erro pode ser uma mensagem enviada a partir do servidor DASH para o cliente DASH incluindo um código de status de erro, como “404 Não encontrado”.

[0062] Em resposta à determinação de que o cliente DASH é capaz de usar uma versão incompleta de um segmento (isto é, bloco de determinação 414 = “Sim”), o servidor DASH pode determinar se o segmento solicitado está parcialmente disponível no bloco de determinação 418. como discutido acima, em resposta à determinação de que o arquivo solicitado não está parcialmente disponível (ou seja, bloco de determinação 418 = “não”), o servidor DASH pode enviar uma mensagem de erro sem o segmento no bloco 416, e o cliente DASH pode receber a mensagem de erro no bloco 424.

[0063] Em resposta à determinação de que o segmento solicitado está parcialmente disponível (ou seja, a bloco de determinação 418 = “Sim”), o servidor DASH pode enviar uma resposta a partir do servidor DASH para o cliente DASH incluindo a versão incompleta de um segmento e um indicação de que o segmento é um segmento parcial no bloco 420. Por exemplo, a resposta pode incluir a “aplicação/3 GPP-parcial”, como Content Tipo indicando que o segmento é um segmento parcial. No bloco 422, o dispositivo cliente pode receber a resposta incluindo a versão incompleta de um segmento. A carga útil da resposta identificado por “application/3GPP-parcial”, como Content- tipo pode ser incluído no código de status HTTP 200 “OK”, o que pode ser formatado como multipart/byteranges com corda limite identificado no cabeçalho Tipo Content. O seguinte mostra um pseudocódigo exemplar de tal resposta, que pode ser recebido pelo cliente DASH assumindo que o servidor DASH tem os conjuntos de intervalos de bytes 0-1999 e 70007999 do segmento requerida de tamanho de 8000 bytes, no momento do DASH servidor recebe a solicitação: Date: Wed, 25 Feb 2015 06:25:24 GMT Content-Length: 3241 Content-Type:application/3gpp-partial; boundary=THIS_STRiNG_SEPARATES —THISSTRINGSEPARATES Content-Type: video/mp4 Content-Range: bytes 0-1999/8000 ...the first range... -THISSTRINGSEPARATES Content-Type: video/mp4 Content-Range: bytes 7000-7999/8000 ...the second range -THIS_STRING_SEPARATES—

[0064] A figura 5 ilustra outro método de modalidade 500 para o manejo de servidor DASH de pedidos do cliente DASH para versões incompletas de segmentos. As operações de processo 500 podem ser semelhantes às operações do método 400 descritos acima, exceto que as operações de processo 500 pode ser realizado após um pedido de segmento inicial é enviado pelo cliente DASH com nenhuma indicação especial em que o cliente DASH pode ser capaz segmento parcial. Em uma modalidade, as operações do processo 500 pode ser realizado por um servidor DASH em comunicação com um cliente DASH para entregar uma resposta incompleta a um pedido de arquivo de mídia a partir do servidor DASH para o cliente DASH.

[0065] Em uma modalidade, um cliente DASH pode enviar pedidos de segmento inicial sem qualquer indicação especial que o cliente DASH é capaz de usar uma versão incompleta de um segmento. Em resposta a receber o segmento requisitado completo, nenhuma ação adicional pode ser tomada pelo cliente DASH. No entanto, o cliente DASH pode monitorar mensagens de erro recebidas em resposta aos pedidos do segmento, e em resposta a receber a mensagem de erro inicial, o cliente DASH pode voltar a pedido do segmento previamente solicitado, desta vez incluindo o campo de cabeçalho indicando que o cliente é capaz de utilizar uma versão incompleta de um segmento. Assim, no bloco 502 a determinação cliente DASH pode determinar se uma mensagem de erro é recebida em resposta a um pedido de segmento. Em resposta à determinação de que nenhuma mensagem de erro é recebida (ou seja, o bloco de determinação 502 = “Não”), o cliente DASH podem continuar a monitorar as mensagens de erro no bloco de determinação 502.

[0066] Em resposta à determinação de que uma mensagem de erro foi recebida (isto é, bloco de determinação 502 = “Sim”), o cliente DASH e o servidor DASH podem executar operações em blocos 402-424 de blocos numerados semelhantes do método 400 descrito acima com referência à figura 4 para tentar receber um segmento parcial em resposta à mensagem de erro.

[0067] A figura 6 ilustra uma outra modalidade 600 para o manejo pelo servidor DASH de pedidos de cliente DASH par versões incompletas de segmentos. As operações do processo 600 pode ser semelhante às operações do método 400 descritos acima, exceto que as operações do método 600 pode ser realizada depois de uma solicitação de segmento inicial é enviado pelo cliente DASH com nenhuma indicação especial em que o cliente DASH é capaz de utilizar segmentos parciais. Em uma modalidade, as operações do método 600 pode ser realizado por um servidor DASH em comunicação com um cliente DASH para entregar uma resposta incompleta a um pedido de arquivo de mídia a partir do servidor DASH para o cliente DASH.

[0068] Em uma modalidade, um cliente DASH pode enviar pedidos de segmento inicial sem qualquer indicação especial que o cliente DASH seja capaz de usar uma versão incompleta de um segmento. Em resposta ao recebimento do segmento requisitado completo, nenhuma ação adicional pode ser tomada pelo cliente DASH. No entanto, o cliente DASH pode monitorar para indicações faixa de bytes e em resposta a receber a indicação faixa de bytes a partir do servidor DASH, o cliente DASH pode solicitar porções subsequentes do segmento utilizando outros intervalos de bytes, desta vez, incluindo o campo de cabeçalho indica que o cliente é capaz de usar uma versão incompleta de um segmento. Assim, no bloco 602 a determinação cliente DASH pode determinar se o faixa de bytes é recebido em resposta a um pedido de segmento. Por exemplo, o cliente pode determinar se DASH uma mensagem conteúdo parcial, incluindo um código de estado 206 e um indicação de faixa de bytes das porções do segmento disponível no servidor são recebidos. Em resposta à determinação de que nenhum faixa de bytes foi recebida (isto é, bloco de determinação 602 = “n”), o cliente DASH pode continuar a monitorizar para um faixa de bytes em bloco de determinação 602. Em resposta à determinação de que uma faixa de bytes for recebida (isto é, bloco de determinação 602 = “Sim”), o cliente DASH e o servidor DASH podem executar operações em blocos 402-424 de blocos numerados como do método 400 acima descrito com referência à figura 4 para tentar receber um segmento parcial em resposta ao faixa de bytes recebida.

[0069] A figura 7 é um fluxograma de chamadas que ilustra as interações entre um cliente DASH e um servidor DASH de acordo com várias modalidades em que o cliente DASH pode gerar um pedido de segmento incluindo, como um campo de cabeçalho Aceitar descrito na RFC 7231, uma indicação de que o cliente é capaz de usar uma versão incompleta de um segmento. Por exemplo, uma operação de GET com a indicação de campo de cabeçalho Aceitar “aplicação/3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento.

[0070] Por exemplo, na série de chamadas 702, o cliente DASH pode enviar um GET com a indicação de campo de cabeçalho Aceitar “application/3GPP-parcial” e como o segmento completo está disponível no servidor DASH, uma resposta 200 com o segmento completo pode ser retornada. Na série de chamadas 704 o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Aceitar “aplicação/3 GPP- parcial” e apenas uma porção do segmento podem estar disponíveis no servidor DASH. Como o cabeçalho Aceitar indica que o cliente DASH é capaz de usar um segmento parcial, o servidor DASH pode determinar o cliente DASH é capaz segmento parcial, e uma resposta 200 com o segmento parcial pode ser devolvido.

[0071] Na série de chamadas 706 o cliente DASH pode inicialmente enviar um GET com nenhuma menção especial capacidade de segmento, e o servidor DASH pode retornar uma mensagem de erro 404 porque somente um segmento parcial está disponível. Em resposta, o cliente DASH pode enviar um GET com a indicação de campo de cabeçalho Aceitar “application/3GPP-parcial” para voltar a pedido do segmento. Porque o cabeçalho Aceitar indica que o cliente DASH é capaz segmento parcial, o servidor DASH pode determinar o cliente DASH é capaz de usar um segmento parcial, e uma resposta 200 com o segmento parcial pode ser devolvido.

[0072] Na série de chamadas 708 o cliente DASH pode inicialmente enviar um GET parcial com uma indicação de faixa de bytes e nenhuma menção especial de capacidade de segmento, e o servidor DASH pode retornar uma mensagem de conteúdo parcial 206 porque o solicitado pelo intervalo que está disponível. Em resposta, o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Aceitar “aplicação/3 GPP-parcial” para solicitar uma porção subsequente do segmento, tal como intervalos de bytes para além de byte 1000. O servidor DASH pode determinar que o cliente DASH seja capaz de usar um segmento parcial com base na indicação no cabeçalho Aceite, e retornar uma resposta parcial conteúdo 206 com qualquer conteúdo para além de 1000 bytes.

[0073] A figura 8 ilustra as interações entre um cliente DASH e servidor DASH de acordo com várias modalidades de acordo com várias modalidades em que o cliente DASH pode gerar um pedido de segmento incluindo uma versão incompleta de uma indicação segmento capaz como um campo de cabeçalho Preferir descrito na RFC 7240. Por exemplo, uma operação GET com a indicação campo de cabeçalho Preferir “retorno = 3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento.

[0074] Por exemplo, na série de chamadas 802, o cliente DASH pode enviar um GET com a indicação de campo de cabeçalho Preferir “retorno = 3GPP-parcial” e como o segmento completo está disponível no servidor DASH, uma resposta 200 com o segmento completo podem ser retornado.

[0075] Na série de chamadas 804, o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Preferir “retorno = 3GPP-parcial”, mas apenas uma parte do segmento podem estar disponíveis no servidor DASH. Porque o cabeçalho Prefere indica que o cliente DASH é capaz de usar um segmento parcial, o servidor DASH pode determinar o cliente DASH é capaz de usar um segmento parcial e retornar uma resposta 200 com o segmento parcial.

[0076] Na série de chamadas 806, o cliente DASH pode inicialmente enviar um GET com nenhuma menção especial capacidade de segmento, e o servidor DASH pode retornar uma mensagem de erro 404 porque somente um segmento parcial podem estar disponíveis. Em resposta, o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Preferir “retorno = 3GPP-parcial” para re-pedido do segmento. O servidor DASH pode determinar o cliente DASH é capaz de usar um segmento parcial com base na indicação Prefere cabeçalho, e retornar uma resposta 200 com o segmento parcial.

[0077] Na série de chamadas 808, o cliente DASH pode inicialmente enviar um GET parcial com uma indicação faixa de bytes e nenhuma menção especial capacidade de segmento, e o servidor DASH pode retornar uma mensagem de conteúdo parcial 206 porque o faixa de bytes solicitado que está disponível. Em resposta, o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Preferir “retorno = 3GPP-parcial” para solicitar uma porção subsequente do segmento, tal como intervalos de bytes para além de byte 1000. Porque o Prefere cabeçalho indica que o cliente é DASH capaz de utilizar um segmento parcial, o servidor DASH pode determinar o cliente DASH é capaz de usar um segmento parcial e retornar uma resposta parcial conteúdo 206 com qualquer conteúdo para além byte 1000.

[0078] A figura 9 ilustra um método de realização 900 para a manejo de servidor DASH de pedidos do cliente para DASH versões incompletas de segmentos. Em uma modalidade, as operações do método 900 pode ser realizado por um servidor DASH em comunicação com um cliente DASH para entregar uma resposta incompleta a um pedido de arquivo de mídia a partir do servidor DASH para o cliente DASH. No bloco 902, o cliente DASH pode gerar um pedido de segmento. O pedido de segmento pode não incluir qualquer indicação especial de capacidade cliente DASH. No bloco 904 o cliente DASH pode enviar o pedido de segmento para o servidor DASH, e no bloco 906 o servidor DASH pode receber o pedido de segmento.

[0079] No bloco de determinação 908, o servidor DASH pode determinar se o segmento solicitado completo está disponível. Em uma modalidade, o servidor DASH pode determinar se o arquivo solicitado completo está disponível por olhar para a URL/URI associado à solicitação de segmento e determinar se o segmento na URL/URI está faltando dados e/ou está danificado de alguma forma. Esses segmentos sem dados ausentes e/ou não incluindo dados corrompidos podem ser determinados como sendo segmentos completos. Esses segmentos sem dados ausentes e/ou incluindo dados corrompidos podem ser determinados como sendo versões incompletas de segmentos.

[0080] Em resposta à determinação que o que o segmento solicitados completo está disponível (ou seja, a bloco de determinação 908 = “Sim”), o servidor DASH pode enviar uma resposta incluindo o segmento solicitados completo no bloco 910, e o cliente DASH pode receber o resposta incluindo o segmento solicitado completo no bloco 912. a resposta pode incluir um código de status indicando que todo o segmento solicitado foi recuperado com sucesso, como 200 “OK”.

[0081] Em resposta à determinação que o segmento completo requerido não está disponível (ou seja, a bloco de determinação 908 = “não”), o servidor DASH pode determinar se o segmento é requerido parcialmente disponível no bloco de determinação 914. Em resposta à determinação que o segmento solicitada não está parcialmente disponível (ou seja, o bloco de determinação 914 = “não”), o servidor DASH pode enviar uma mensagem de erro, sem qualquer porção do segmento solicitado para o cliente DASH no bloco 916, e o cliente DASH pode receber a mensagem de erro no bloco 918. Em uma modalidade, a mensagem de erro pode ser uma mensagem enviada a partir do servidor DASH para o cliente DASH incluindo um código de status de erro, como “404 Not Found.”

[0082] Em resposta à determinação que o segmento está parcialmente disponível (ou seja, a bloco de determinação 914 = “Sim”), o servidor DASH pode enviar uma resposta a partir do servidor DASH para o cliente DASH incluindo uma indicação de que uma versão incompleta do segmento está disponível no servidor DASH no bloco 920, e o cliente DASH pode receber a resposta no bloco 922. Em uma modalidade, a mensagem de resposta pode incluir uma indicação de que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes do segmento que estão disponíveis. Em uma modalidade, a mensagem de resposta pode ser uma mensagem que inclui uma extensão de cabeçalho indica que uma versão incompleta do segmento pedido estiver disponível e a intervalos de bytes disponíveis. Por exemplo, a resposta inicial pode ser uma mensagem de erro inclui um código de status 404 e um cabeçalho de extensão “X- Disponíveis: bytes ab, cd, ...”. Como outro exemplo, a resposta inicial pode ser uma mensagem de conteúdo parcial, incluindo um código de status 206 e extensão cabeçalho “X - Faixas Disponíveis Ranges: bytes ab, cd, ...”. Em uma modalidade, a mensagem de resposta pode ser uma mensagem de redirecionamento, tal como uma mensagem de série 300, incluindo um corpo de entidade indicando que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes que estão disponíveis, tal como “Content-Type = 3GPP-parcial - byte-ranges”.

[0083] No bloco 924, o cliente DASH pode gerar um pedido de segmento. O pedido de segmento pode ser gerado para receber uma versão incompleta de um segmento. O pedido de segmento pode incluir uma indicação de que o cliente é capaz de usar uma versão incompleta de um segmento. Por exemplo, uma operação de GET com o cabeçalho aceitar indicação campo “aplicação/3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento. Em uma modalidade, o pedido de segmento para uma versão incompleta de um segmento pode ser uma operação de “GET parcial” (isto é, método), incluindo uma indicação do byte faixas o servidor DASH indicado estavam disponíveis para o segmento. No bloco 926, o cliente DASH pode enviar o pedido de segmento para o servidor DASH, e no bloco 928 o servidor DASH pode receber o pedido de segmento.

[0084] Em resposta ao recebimento do pedido de segmento com os intervalos de bytes indicados, o servidor DASH pode enviar uma resposta para o cliente DASH incluindo a versão incompleta de um segmento no bloco 930. Em uma modalidade, a resposta, incluindo a versão incompleta do segmento pode incluir uma indicação de que o segmento é um segmento parcial. Por exemplo, a resposta pode incluir a “de várias vias/byteranges” como Content-Type com indicação de contorno associado, tal como “fronteira = THIS_STRING_SEPARATES”, indicando que o segmento é um segmento parcial. No bloco 932, o cliente pode receber a resposta incluindo a versão incompleta de um segmento.

[0085] A figura 10 ilustra as interações entre um cliente DASH e servidor DASH de acordo com várias modalidades em que a mensagem de resposta inicialmente enviado a partir do servidor de colisão é uma mensagem que inclui uma extensão de cabeçalho indica que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes que estão disponíveis .

[0086] Por exemplo, na série de chamadas 1004 a resposta inicial a um GET do cliente DASH pode ser uma mensagem de erro do servidor DASH incluindo um código de status 406 e uma extensão cabeçalho “X - Faixas Disponíveis: bytes ab, cd, ...”. Um segmento parcial DASH cliente capaz pode interpretar o cabeçalho de extensão como uma indicação de que um segmento parcial está disponível, e podem enviar um pedido GET parcial, incluindo uma indicação do byte varia que o servidor DASH indicado estavam disponíveis para o segmento. Com base nos intervalos de bytes indicados no pedido GET, o servidor DASH pode devolver uma resposta parcial conteúdo 206, com as faixas disponíveis segmento solicitados.

[0087] Como outro exemplo, em série de chamadas 1006 a resposta inicial a um GET do cliente DASH pode ser uma mensagem de conteúdo parcial, incluindo um código de status 206 e extensão cabeçalho “X - Faixas Disponíveis: bytes ab, cd”. Um cliente DASH-parcial do segmento capaz pode interpretar o cabeçalho de extensão como uma indicação de que um segmento parcial está disponível e pode enviar um pedido GET parcial, incluindo uma indicação do byte varia que o servidor DASH indicado estavam disponíveis para o segmento. Com base nos intervalos de bytes incluídos no pedido GET o servidor DASH pode devolver uma resposta parcial conteúdo 206, com as faixas disponíveis segmento solicitados.

[0088] A figura 11 ilustra as interações entre um cliente DASH e servidor DASH de acordo com várias modalidades em que a mensagem de resposta inicial a partir do servidor de colisão é uma mensagem de redirecionamento, tais como uma mensagem de série 300, incluindo um corpo de entidade indicando que uma versão incompleta do segmento solicitado é disponível e os intervalos de bytes que estão disponíveis, tais como “conteúdo-Tipo = 3GPP parcial de bytes-faixas”.

[0089] Por exemplo, nas séries de chamada 1104 a resposta inicial a um GET do cliente DASH pode ser uma mensagem de redirecionamento, tal como uma mensagem de série 300, incluindo um corpo de entidade indicando que uma versão incompleta do segmento pedido estiver disponível e a intervalos de bytes que estão disponíveis, tais como “conteúdo-Tipo = 3GPP parcial de bytes-faixas”. Desta forma, o servidor DASH não pode redirecionar o cliente DASH, mas sim direcionar o cliente de volta para o mesmo segmento apenas com uma indicação de que o segmento está apenas parcialmente disponível. Um cliente DASH capaz segmento parcial pode interpretar a mensagem 300 com o corpo da entidade como o que indica que um segmento parcial pode estar disponível e pode enviar um pedido GET parcial, incluindo uma indicação do byte varia que o servidor DASH indicado estavam disponíveis para o segmento. Com base nos intervalos de bytes incluído no pedido GET, o servidor DASH pode retornar uma resposta conteúdo parcial 206 com os intervalos de segmentos disponíveis solicitados.

[0090] Como outro exemplo, em série de chamadas 1106 o cliente DASH pode inicialmente enviar um GET parcial com uma indicação faixa de bytes e nenhuma menção especial capacidade de segmento, e o servidor DASH pode retornar uma mensagem de conteúdo parcial 206 com o faixa de bytes solicitado que é acessível. O cliente DASH pode então enviar um pedido GET parcial para solicitar uma porção subsequente do segmento, tal como intervalos de bytes além byte 1000. Porque um segmento parcial além byte 1000 está disponível, a resposta a partir do servidor DASH pode ser uma mensagem de redirecionamento, tais como uma mensagem de série 300, incluindo um corpo de entidade indicando que uma versão incompleta do segmento solicitado está disponível e os intervalos de bytes que estão disponíveis, tais como “conteúdo-Tipo = 3GPP-parcial - byte - faixas”. Desta forma, o servidor DASH não pode redirecionar o cliente DASH, mas sim direcionar o cliente de volta para o mesmo segmento apenas com a indicação do segmento está apenas parcialmente disponível. Um cliente DASH capaz segmento parcial pode interpretar a mensagem 300 com o corpo da entidade como o que indica que um segmento parcial está disponível e pode enviar um pedido GET incluindo uma indicação do byte varia que o servidor DASH indicado estavam disponíveis para além de bytes 1000 para o segmento. Com base nos intervalos de bytes incluídos no pedido GET o servidor DASH pode devolver uma resposta parcial conteúdo 206 com o segmento disponível requerida varia além byte 1000.

[0091] A figura 12 ilustra outro método de modalidade 1200 para manejo pelo servidor DASH de pedidos do cliente para DASH versões incompletas de segmentos. As operações do método de 1200 podem ser semelhantes às operações do método 400 descrito acima, exceto que as operações de método 1200 pode ser realizado quando as posições de acesso são associadas com os segmentos. Em uma modalidade, as operações do método de 1200 pode ser realizado por um servidor DASH em comunicação com um cliente DASH para entregar uma resposta incompleta a um pedido de arquivo de mídia a partir do servidor DASH para o cliente DASH. Em blocos 402-424 DASH o cliente e servidor DASH podem executar operações de blocos numerados como do método 400 acima descrito com referência à figura 4 para fornecer respostas, incluindo as mensagens de segmento ou de erro solicitados completos quando o cliente não é capaz de usar versões incompletas de segmentos.

[0092] Em resposta à determinação que o cliente DASH é capaz de usar uma versão incompleta de um segmento (isto é, bloco de determinação 414 = “Sim”), o servidor DASH pode determinar se o FDT recebido indicado o segmento solicitado pelo cliente DASH foi enviado para o servidor DASH em bloco de determinação 1202. ao marcar o FDT para a representação DASH incluindo o segmento solicitado, o servidor DASH pode determinar se o segmento solicitado é um segmento real associado com a representação. Desta forma, o servidor DASH pode distinguir solicitações equivocadas de segmentos de um fluxo de mídia a partir de solicitações válidas para segmentos de um fluxo de mídia.

[0093] Em resposta à determinação que o FDT não incluir o segmento de pedido (ou seja, o bloco de determinação 1202 = “n”), nos blocos 416 e 424 o servidor DASH e cliente DASH podem executar operações de blocos numerados como do método 400 descrito acima com referência à figura 4, a fim de indicar um erro.

[0094] Em resposta à determinação que o FDT que lista o segmento requerido (isto é, bloco de determinação 1202 = “Sim”), o servidor DASH pode determinar se o segmento é requerido parcialmente disponível no bloco de determinação 418. Em resposta à determinação que o arquivo solicitado não está parcialmente disponível (ou seja, bloco de determinação 418 = “não”), o servidor DASH pode enviar uma mensagem de erro sem o segmento no bloco 1212. desta forma, o servidor DASH pode gerar e enviar uma mensagem de erro em resposta a um cliente DASH capaz de usar uma versão incompleta de um segmento solicitando um segmento para o qual há bytes estão disponíveis no servidor DASH. Por exemplo, o servidor DASH pode enviar uma mensagem de erro inclui um código de status 416 “Intervalo solicitado não satisfatório”, quando há bytes para um segmento DASH ou byte intervalo solicitado de um segmento DASH estão disponíveis no servidor DASH. A mensagem de erro pode indicar ainda o tipo de conteúdo proporcionado no exemplo FDT para o segmento DASH, a localização conteúdo fornecido na FDT para o segmento DASH, e o faixa conteúdo indicado como “bytes */conteúdo de comprimento” com base no comprimento do conteúdo indicado na FDT para o segmento DASH.

[0095] No bloco 1214 o cliente DASH pode receber a mensagem de erro. Ao receber uma mensagem de erro inclui um código de status 416 “Intervalo solicitado não satisfatório”, o cliente DASH pode distinguir entre pedidos de segmentos inválidos (por exemplo, solicita resultando em mensagens de erro com um código de status 404 “Não Encontrado”) e os pedidos de segmentos que foram perdidos na transmissão (por exemplo, segmentos indicados na FDT mas sem bytes recebidos, resultando em mensagens de erro com um código de status 416 “Intervalo solicitado não satisfatório”). Em uma modalidade, o cliente DASH pode esconder os perdidos no segmento de transmissão indicado pela mensagem de erro com o código de estado 416 e continuar a operação normal, solicitando o segmento seguinte na representação.

[0096] Em resposta à determinação que o segmento solicitado está parcialmente disponível (ou seja, a bloco de determinação 418 = “Sim”), o servidor DASH pode enviar uma resposta a partir do servidor DASH para o cliente DASH incluindo a versão incompleta de um segmento, uma indicação de que o segmento é um segmento parcial, e uma indicação de um ou mais posições de acesso para o segmento no bloco 1208. Por exemplo, a resposta pode incluir a “aplicação/3GPP-parcial”, como Tipo de Conteúdo indicando que o segmento é um segmento parcial e os campos de cabeçalho de extensão “3GPP-acesso da posição” indicando um ou mais posições de byte no segmento DASH no qual o cliente DASH pode aceder ao segmento. A resposta pode ainda incluir uma indicação da porção do segmento incluído na resposta. Por exemplo, a resposta pode incluir um ou mais campos de cabeçalho (por exemplo, um campo de cabeçalho conteúdo- faixa) que indicam um ou mais intervalos de bytes do segmento incluído na resposta. Em tais modalidades, em que a resposta inclui um ou mais campos de cabeçalho que indicam um ou mais intervalos de bytes do segmento incluído na resposta, mais campos de um ou de cabeçalho de extensão “3GPP-Acesso-posição” pode incluir uma ou mais posições de byte, que são em um ou mais intervalos de bytes indicados e em que o cliente pode aceder ao DASH segmento. Em diversas modalidades, os um ou mais posições de acesso para o segmento pode ser indicado para o servidor DASH como um “mbms2015: IndependentUnitPositions” atributo da entrada de uma instância FDT da versão incompleta recebeu do segmento DASH arquivo. Quando as entradas de todas as instâncias FDT da versão incompleta recebeu do segmento DASH arquivo não incluir um “mbms2015: IndependentUnitPositions” atributo, o servidor DASH pode analisar a versão incompleta recebeu do segmento DASH para determinar um ou mais cabeçalhos de fragmentos de filme (moofs localizações) para identificar um ou mais moofs como uma ou mais posições de acesso para o segmento.

[0097] No bloco 1210, o cliente DASH pode receber a resposta incluindo a versão incompleta de um segmento, a indicação de que a resposta inclui um segmento parcial, e a indicação de um ou mais pontos de acesso. A resposta recebida pode também incluir uma indicação da porção do segmento incluído na resposta, por exemplo, em um campo de cabeçalho de conteúdo - faixa. A carga útil da resposta identificado por “application/3GPP-parcial”, como Content-tipo pode ser incluído no código de status HTTP 200 “OK”, o que pode ser formatado como multipart/byteranges com corda limite identificado no cabeçalho Tipo Content e uma ou mais posições de byte separados por vírgulas (comma- separated byte positions) correspondentes ao ponto (s) de acesso para o segmento indicado no campo “3GPP-acesso- posição”.

[0098] Em um exemplo, o servidor pode ter DASH os conjuntos de intervalos de bytes 0-19999, 50000-85000, 105.500-199.888, e 201515-229566 do segmento solicitados do tamanho 256000 bytes no tempo que o servidor recebe o pedido DASH , e a entrada de arquivo para uma instância FDT para o segmento DASH pode incluir o atributo “mbms2015: IndependentUnitPositions” com a seguinte lista de valores “0 60000 80000 110000”. Em tal exemplo, o servidor DASH pode identificar os intervalos de bytes da primeira posição de acesso como: 0-59999, a segunda posição de acesso como: 60000-79999, a terceira posição de acesso como: 80.000109.999, e a quarta posição de acesso, conforme: 110000255999. Porque o primeiro byte raiva disponível para o servidor DASH (0-19999) contém o início do primeiro posio de acesso, o servidor pode incluir DASH “3GPP-Acesso- posição: 0” na resposta. O segundo faixa de bytes disponíveis para o servidor DASH (50000-85000) pode conter a segunda posição de acesso e parte da terceira posição de acesso, e, por conseguinte, o servidor pode incluir DASH “3GPP- acesso - posição: 60000, 80000” como resposta. Da mesma forma, o terceiro faixa de bytes disponíveis para o servidor DASH (105500-199888) podem conter parte da quarta posição de acesso, e, por conseguinte, o servidor pode incluir DASH “3GPP-Acesso-posição: 110000” em resposta a. Finalmente, o quarto faixa de bytes disponíveis para o servidor DASH (201515-229566) pode não conter o início de qualquer posição de acesso, e como resultado, o servidor DASH pode não incluir “3GPP-acesso - posição” elemento na resposta. O seguinte mostra um exemplo em pseudocódigo de uma tal resposta, que pode ser recebido pelo cliente DASH: HTTP/1.1200OK Content-Length: 172441 Content-Type: application/3gpp-partial; boundary=SEPARATION_STRING Cache-Control: no-cache - SEPARATIONSTRING Content-type video/mp4 Content-range: bytes 0-19999/256000 3gpp-access-position: 0 ...< the first range>... - SEPARATIONSTRING Content-type video/mp4 Content-range: bytes 50000-85000/256000 3gpp-access-position: 60000,80000 ...<the second range>... — SEPARATIONSTRING Content-type: video/mp4 Content-range: bytes 105500-199888/256000 3gpp-access- position: 110000 ...<the third range >. . . - SEPARATIONSTRING Content-type: video/mp4 Content-range: bytes 201515-229566/256000 ...< the fourth range >. . . -SEPARATION_STRING -

[0099] A figura 13 é um fluxograma de chamadas que ilustra as interações entre um cliente DASH e um servidor DASH de acordo com várias modalidades em que o cliente DASH pode gerar um pedido de segmento. O pedido de segmento pode incluir, como um campo de cabeçalho Aceitar descrito no RFC 7231, uma indicação de que o cliente é capaz de usar uma versão incompleta de um segmento. Por exemplo, uma operação de GET com a indicação de campo de cabeçalho Aceitar “aplicação/3GPP-parcial” pode indicar que o cliente DASH irá aceitar segmentos parciais em resposta ao pedido de segmento.

[00100] Por exemplo, na série de chamadas 1302, o cliente DASH pode enviar um GET com o Aceitar indicação campo de cabeçalho “application/3GPP-parcial”, e porque o segmento completo está disponível no servidor DASH, uma resposta 200 com a plena segmento pode ser devolvido.

[00101] Na série de chamadas 1304 o cliente pode enviar um DASH GET com a indicação de campo de cabeçalho Aceitar “aplicação/3 GPP-parcial.” Se apenas uma parte do segmento está disponível no servidor DASH e o Aceite cabeçalho indica que o cliente DASH é capaz de usar um segmento parcial, o servidor DASH pode determinar que o cliente DASH seja segmento parcial capaz, e pode enviar para o DASH cliente uma resposta 200 com o segmento parcial, o tipo de conteúdo segmento indicação campo de cabeçalho parcial “aplicação/3GPP-parcial”, e a indicação da posição de acesso campo de cabeçalho “3GPP-acesso- posição.”

[00102] Na série de chamadas 1306 o cliente DASH pode enviar um GET com a indicação Aceitar campo de cabeçalho “application/3 GPP-parcial”. Se nenhum bytes do segmento pode estar disponível no servidor DASH e o cabeçalho Aceitar indica que o cliente DASH é capaz de usar um segmento parcial, o servidor DASH pode determinar o cliente DASH é o segmento parcial capaz, e enviar para o DASH cliente um 416 “intervalo solicitado não satisfatório” mensagem de erro com o tipo de conteúdo indicação campo do cabeçalho “/ 3 GPP-parcial aplicação”, e o conteúdo-faixa “bytes */conteúdo de comprimento.”

[00103] A figura 14 é um diagrama de blocos de dados de segmentos de uma corrente de media, tais como um fluxo de meios DASH. Um fluxo de multimídia pode incluir um segmento de inicialização e vários segmentos de meios, tais como um segmento de meios de comunicação, meios segmento 2, etc. Um segmento de mídia podem incluir um ou mais moofs incluindo metadados, tais como dados indicando os pontos de acesso aleatório (por exemplo, pontos de acesso Corrente (PAE) do tipo 1 ou 2) ou amostras de sincronização, que pode ser utilizado por um cliente DASH para decodificar e/ou tornar as partes de dados um ou mais meios de comunicação (mdats) do segmento de meios de comunicação (por exemplo, os intervalos de bytes do segmento de mídia incluindo o vídeo, áudio, etc. amostras de dados). Nas várias modalidades, a porção inicial do segmento de meios pode ser o faixa de bytes do segmento de mídia correspondente para o primeiro Moof do segmento.

[00104] Sem o primeiro Moof do segmento de meios de comunicação, os mdats do segmento não podem ser facilmente analisável e a posição inicial de quaisquer moofs adicionais no segmento não podem ser localizados pelo cliente DASH porque o tamanho do Moof e MDAT pode ser desconhecido para o cliente DASH. As várias modalidades podem fornecer uma indicação da posição de acesso (por exemplo, indicado pelo atributo “3GPP-Acesso-posição”) que podem identificar uma posição de byte no segmento de meios de comunicação em que o cliente DASH pode aceder ao segmento para começar a análise de uma versão incompleta o segmento para identificar pontos de acesso aleatório (por exemplo, jogos de pontos de acesso (PAE) do tipo 1 ou 2) ou amostras de sincronização que pode ser usado para decodificar e/ou tornar a versão incompleta do segmento. Deste modo, a posição de acesso pode ser uma posição de byte intermediário na faixa de bytes solicitada ou segmento solicitado que pode permiti que o cliente DASH para analisar uma versão incompleta do segmento quando a porção inicial do segmento (por exemplo, o primeiro Moof do segmento) podem ser perdidos.

[00105] Por exemplo, como ilustrado na figura 14, moofl e uma porção de mdatl para meios segmento 1 pode ser perdido na transmissão resultante no servidor DASH apenas fornecer a versão incompleta do segmento de mídia 1 a um cliente DASH requerente. Por indicando que a versão incompleta do segmento de mídia 1 é fornecida e que indica a posição de byte de ponto de acesso no elemento “3GPP- Acesso-posição”, o cliente DASH pode determinar se a versão incompleta inclui a porção inicial (por exemplo, Moof 1). Em resposta à determinação de que a porção inicial do segmento (por exemplo, Moof 1) é perdido e não na versão incompleta, o cliente pode iniciar a análise DASH na posição de acesso. Desta maneira, os dados de meta em Moof 2, tais como os dados que indicam pontos de acesso aleatório (por exemplo, pontos de fluxo de acesso (PAE) do tipo 1 ou 2) ou amostras de sincronização, pode permitir que o cliente DASH para decodificar e/ou tornar mdat2 e depois segmentos de meios, tais como meios segmento 2.

[00106] A figura 15 ilustra um método de modalidade 1500 para um manuseamento cliente DASH de versões incompletas de segmentos. Em uma modalidade, as operações do método de 1500 pode ser efetuada por um cliente DASH para analisar uma resposta incompleta a um pedido de arquivo de mídia. Como discutido acima, no bloco 1210 o cliente pode receber a DASH resposta incluindo a versão incompleta de um segmento, a indicação de que a resposta inclui um segmento parcial, e a indicação de um ou mais pontos de acesso. Por exemplo, a resposta pode incluir a “aplicação/3GPP-parcial”, como Content-Type indicando que o segmento é um segmento parcial e a campos de cabeçalho extensão “3GPP-Acesso-posição”, indicando um ou mais posições de byte no segmento DASH em que o cliente DASH pode acessar o segmento.

[00107] No bloco de determinação opcional 1501 o cliente DASH pode determinar se uma porção inicial do segmento foi recebido na resposta incompleta. Nas várias modalidades, a porção inicial do segmento de meios pode ser o faixa de bytes do segmento de mídia correspondente para o primeiro Moof do segmento. Em resposta a determinar a porção inicial do segmento é recebida (isto é, bloco de determinação 1501 = “Sim”), o cliente pode DASH analisar a versão incompleta do segmento começando no primeiro byte da porção inicial no bloco 1503.

[00108] Em resposta à determinação de que a porção inicial do segmento não foi recebida (isto é, o bloco de determinação 1501 = “não”) ou em modalidades em que o cliente DASH não pode ser configurado para verificar se há uma porção inicial, o cliente DASH pode determinar se um byte na posição de acesso é recebido na versão incompleta do segmento em bloco de determinação 1502. em resposta à determinação que o byte correspondente para a posição de acesso não é recebido (isto é, bloco de determinação 1502 = “não”), o cliente pode pedir DASH o segmento seguinte na representação em bloco 1504. Em resposta à determinação que o byte correspondente para a posição de acesso é recebido (isto é, bloco de determinação 1502 = “Sim”), o DASH cliente pode analisar a versão incompleta do segmento começando na posição de acesso no bloco 1506.

[00109] As várias modalidades (que incluem, mas não se limitam a, modalidades descritas acima com referência às figuras 4-15) podem ser implementadas em qualquer de uma variedade de dispositivos móveis (isto é, dispositivos de receptor), um exemplo da qual é ilustrada na figura 16. Por exemplo, o dispositivo de computação móvel 1600 pode incluir um processador 1601 acoplado a um controlador de tela sensível ao toque 1604 e uma memória interna 1602. O processador 1601 pode ser um ou mais circuitos de vários núcleos integrados (ICs) designados para funções gerais ou específicos de processamento. A memória interna 1602 pode ser de memória volátil ou não volátil, e pode também ser protegido e/ou memória codificada, ou não seguro e/ou a memória não criptografada, ou qualquer combinação dos mesmos. O controlador de tela sensível ao toque 1604 e o processador 1601 pode também ser acoplado a um painel de tela sensível ao toque 1612, tal como uma tela resistiva de detecção de toque, tela sensível ao toque capacitiva, tela sensível ao toque de detecção de infravermelhos, etc. O dispositivo de computação móvel 1600 pode ter uma ou transceptores de rádio do sinal mais 1608 (por exemplo, Peanut®, Bluetooth, ZigBee®, Wi-Fi, celular, etc.) e de antenas de 1610, para emitir e receber, acoplados uns aos outros e/ou para o processador 1601. os transceptores 1608 e 1610 antenas pode ser utilizado com os circuitos acima mencionados para implementar as várias pilhas e interfaces sem fios de protocolo de transmissão. O dispositivo de computação móvel 1600 pode incluir uma rede celular de chip modem sem fios 1616 que permite a comunicação através de uma rede celular e é acoplada ao processador. O dispositivo de computação móvel 1600 pode incluir uma interface de ligação do dispositivo periférico 1618 acoplado ao processador 1601. A interface de ligação do dispositivo periférico 1618 pode ser singularmente configurada para aceitar um tipo de ligação, ou multiplamente configurado para aceitar diferentes tipos de ligações físicas e de comunicação, comum ou proprietárias, tais como USB, FireWire, Thunderbolt, ou PCIe. A interface de ligação do dispositivo periférico 1618 pode também ser acoplado a uma porta de ligação entre o dispositivo periférico configurado de forma semelhante (não mostrado). O dispositivo de computação móvel 1600 também pode incluir alto-falantes 1614 para fornecer saídas de áudio. O dispositivo de computação móvel 1600 pode também incluir um alojamento 1620, construído de um plástico, de metal, ou uma combinação de materiais, para conter todos ou alguns dos componentes aqui discutidos. O dispositivo de computação móvel 1600 pode incluir uma fonte de energia 1622 acoplado ao processador 1601, tal como uma bateria descartável ou recarregável. A bateria recarregável pode também ser acoplada à porta de ligação periférico para receber uma corrente de carga a partir de uma fonte externa para o dispositivo de computação móvel 1.600.

[00110] As várias modalidades (que incluem, mas não se limitam a, modalidades descritas acima com referência às figuras 4-15) também podem ser implementadas em qualquer de uma variedade de dispositivos servidores disponíveis comercialmente, tais como o servidor 1700 ilustrado na figura 17. Tal servidor 1700 inclui, tipicamente, um processador 1701 acoplado a memória volátil 1702 e uma memória não volátil de grande capacidade, tal como uma unidade de disco 1704. O servidor 1700 pode também incluir uma unidade de disco flexível, disco compacto (CD) ou uma unidade de disco de DVD 1706 acoplado ao processador 1701. o servidor 1700 pode também incluir um ou mais transceptores de rede 1703, como uma porta de acesso à rede, acoplados ao processador 1701 para o estabelecimento de ligações de interface de rede com uma rede de comunicações 1707, como uma rede de área local acoplado para outros computadores sistema de anúncio e servidores, a Internet, a rede telefônica pública comutada, e/ou uma rede celular (por exemplo, CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, ou qualquer outro tipo de rede celular).

[00111] Os processadores 1601 e 1701 podem ser qualquer microprocessador programável, microcomputador ou microchip do processador múltiplo ou chips que podem ser configurados por instruções de software (aplicações) para executar uma variedade de funções, incluindo as funções das várias modalidades descritas acima. Em alguns dispositivos, processadores múltiplos podem ser fornecidos, tal como um processador dedicado para funções de comunicação sem fio e um processador dedicado à execução de outras aplicações. Tipicamente, o software aplicações podem ser armazenados na memória interna antes que eles são acessados e carregado para os processadores 1601 e 1701. Os processadores 1601 e 1701 podem incluir memória interna suficiente para armazenar as instruções de software de aplicação. Em muitos dispositivos de memória interna pode ser uma memória volátil ou não volátil, tal como memória flash, ou uma mistura de ambos. Para os fins desta descrição, uma referência geral para a memória refere-se à memória acessível por os processadores 1601 e 1701, incluindo a memória interna ou de memória removível ligado ao dispositivo e da memória, dentro dos processadores 1601 e 1701 si.

[00112] As descrições de métodos anteriores e os diagramas de fluxo de processo são fornecidos meramente como exemplos ilustrativos e não se destinam a impor ou implicar que os passos de várias modalidades devem ser realizados na ordem apresentada. Como será apreciado por um perito na arte a ordem dos passos nas modalidades anteriores podem ser realizados em qualquer ordem. As palavras “depois”, “em seguida”, “lado”, etc., não se destinam a limitar a ordem dos passos de; estas palavras são simplesmente usadas para orientar o leitor através da descrição dos métodos. Além disso, qualquer referência a elementos de reivindicação no singular, por exemplo, usando os artigos “um”, “uma” ou “a” não é para ser interpretado como limitando o elemento ao singular.

[00113] Os vários blocos, módulos, circuitos e etapas de algoritmo ilustrativos lógicos descritas em ligação com as modalidades aqui divulgadas podem ser implementados como hardware eletrônico, software de computador, ou combinações de ambos. Para ilustrar claramente esta permutabilidade de hardware e software, vários componentes ilustrativos, blocos, módulos, circuitos, e passos foram descritos acima, geralmente em termos da sua funcionalidade. Se tal funcionalidade é implementada como hardware ou software depende da aplicação e design limitações específicas impostas ao sistema global. Os especialistas na técnica podem implementar a funcionalidade descrita de maneiras diferentes para cada aplicação particular, mas tais decisões de execução não devem ser interpretadas como causando um afastamento do escopo da presente invenção.

[00114] O equipamento utilizado para implementar as várias lógicas ilustrativas, blocos lógicos, módulos, e circuitos descritos em ligação com os aspectos aqui divulgados podem ser implementados ou executados com um processador de uso geral, um processador de sinal digital (DSP), um pedido específico circuito integrado (ASIC), um campo matriz programável portão (FPGA) ou outro dispositivo lico programel, porta discreta ou lógica transistor, componentes de hardware discretos, ou qualquer combinao dos mesmos concebidos para executar as funes aqui descritas. Um processador de uso geral pode ser um microprocessador, mas, em alternativa, o processador pode ser qualquer processador convencional, controlador, microcontrolador, ou máquina de estados convencional. Um processador pode tamb ser implementado como uma combinao de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo DSP, ou qualquer outro tipo de configuração. Alternativamente, alguns passos ou métodos podem ser realizados por circuitos que é específica para uma dada função.

[00115] Em um ou mais aspectos exemplares, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementado em software, as funções podem ser armazenadas como uma ou mais instruções ou código em um meio legível por computador não transitório ou médio processador legível não transitório. Os passos de um processo ou algoritmo aqui descrito pode ser incorporado em um módulo de software executável-processador e/ou instruções de processador- executável, o qual pode residir em um meio de armazenamento legível por processador não transitório ou legível por computador não transitório. Servidor de leitura não transitório, meios de armazenamento legíveis por computador ou processador de leitura pode ser qualquer mídia de armazenamento que pode ser acessado por um computador ou um processador. A título de exemplo, mas não limitativo, tal não transitório servidor legível, meios legíveis por computador ou processador de leitura pode incluir RAM, ROM, EEPROM, memória flash, CD-ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outro magnética dispositivos de armazenamento ou qualquer outro meio que pode ser usado para armazenar o código de programa desejado sob a forma de instruções ou estruturas de dados, e que pode ser acedido por um computador. Disco e disco, como aqui utilizado, inclui disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray onde os discos geralmente reproduzem dados magneticamente, enquanto que os discos reproduzem dados opticamente com lasers. Combinações dos anteriores também estão incluídos no âmbito da legível em computador e processador legível por meios não transitório servidor legível. Além disso, as operações de um método ou algoritmo podem residir, como uma ou qualquer combinação ou conjunto de códigos e/ou instruções em um meio legível por processador, meio de leitura por computador, legível por servidor de forma não transitória e/ou, que pode ser incorporadas em um produto de programa de computador.

[00116] A descrição anterior das modalidades reveladas proporcionada para permitir que aqueles versados na arte possam fazer ou utilizar a presente invenção. Várias modificações a estas modalidades serão prontamente aparentes para aqueles versados na arte, e os princípios genéricos aqui definidos poderão ser aplicados a outras modalidades sem se afastar do espírito ou âmbito da invenção. Assim, a presente invenção não se destina a ser limitada às modalidades aqui mostradas, mas deve ser concedido o mais vasto âmbito consistente com as reivindicações seguintes e os princípios e características inovadoras aqui apresentadas.

Claims

1. Método para entregar uma resposta incompleta a uma solicitação de arquivo de mídia a partir de um servidor (112) para um cliente (102), compreendendo: receber (406) uma solicitação de segmento no servidor a partir do cliente, em que a solicitação de segmento indica se o cliente é capaz de usar um segmento incompleto; determinar (408), no servidor, se um segmento completo associado com a solicitação de segmento está disponível no servidor; determinar (414), no servidor, com base na solicitação de segmento, se o cliente é capaz de usar um segmento incompleto em resposta ao segmento completo associado com a solicitação de segmento não estando disponível no servidor; e enviar (420) a partir do servidor para o cliente um segmento incompleto em uma mensagem de resposta incluindo: uma indicação de que a mensagem de resposta inclui o segmento incompleto; uma indicação de uma porção de um segmento solicitado que é incluído no segmento incompleto incluído na mensagem de resposta, em que a indicação da porção do segmento solicitado que é incluída no segmento incompleto compreende uma indicação de uma faixa de bytes dentro do segmento solicitado que é incluída no segmento incompleto; o método caracterizado pelo fato de que a mensagem de resposta inclui adicionalmente uma indicação de uma ou mais posições de acesso para o segmento incompleto em resposta à determinação de que o cliente é capaz de usar um segmento incompleto, em que as uma ou mais posições de acesso identificam um ou mais pontos dentro do segmento incompleto nos quais se começa a analisar para decodificar o segmento incompleto.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que uma ou ambas as indicações de que a mensagem de resposta inclui o segmento incompleto e a indicação de uma ou mais posições de acesso para o segmento incompleto são campos de cabeçalho separados na mensagem de resposta.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que um ou mais campos de cabeçalho da mensagem de resposta incluem a indicação da porção do segmento solicitado que é incluído no segmento incompleto.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que as uma ou mais posições de acesso para o segmento incompleto são localizadas dentro da faixa de bytes dentro do segmento solicitado que é incluída no segmento incompleto.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as uma ou mais posições de acesso são uma ou mais posições de bytes intermediárias em uma faixa de bytes de um segmento associado com a solicitação de segmento.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que pelo menos uma posição de acesso está fora de uma porção inicial do segmento associado com a solicitação de segmento.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que a porção inicial do segmento associado com a solicitação de segmento é um primeiro cabeçalho de fragmento de filme do segmento.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as uma ou mais posições de acesso são indicadas em uma Tabela de Entrega de Arquivo, FDT, descrevendo um segmento associado com a solicitação de segmento.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que as uma ou mais posições de acesso são indicadas por uma ou mais posições de bytes separadas por vírgula na FDT.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: determinar no servidor se nenhum byte associado à solicitação de segmento está disponível no servidor em resposta à determinação de que o cliente é capaz de utilizar um segmento incompleto; e enviar a partir do servidor para o cliente uma mensagem de erro em resposta à determinação de que nenhum byte associado à solicitação de segmento está disponível no servidor, em que o envio a partir do servidor para o cliente de um segmento incompleto em uma mensagem de resposta incluindo uma indicação de que a mensagem de resposta inclui o segmento incompleto e uma indicação de uma ou mais posições de acesso para o segmento incompleto em resposta à determinação de que o cliente seja capaz de utilizar um segmento incompleto compreende enviar a partir do servidor para o cliente um segmento incompleto em uma mensagem de resposta que inclui uma indicação de que a mensagem de resposta inclui o segmento incompleto e uma indicação de uma ou mais posições de acesso para o segmento incompleto em resposta à determinação de que o cliente seja capaz de usar um segmento incompleto e determinar que um byte associado com a solicitação de segmento esteja disponível no servidor.

11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que mensagem de erro indica que nenhum byte associado com a solicitação de segmento está disponível no servidor.

12. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que a mensagem de erro inclui um código de status 416.

13. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o cliente é um cliente de Fluxo Contínuo Adaptativo Dinâmico, DASH, sobre Protocolo de Transferência de Hipertexto e o servidor é um servidor DASH.

14. Servidor, caracterizado pelo fato de que compreende: um processador configurado com instruções executáveis por processador para realizar operações que compreendem o método conforme definido em qualquer uma das reivindicações 1 a 13.

15. Memória legível por computador caracterizada pelo fato de que compreende instruções armazenadas na mesma que, quando executadas, fazem com que um computador realize o método conforme definido em qualquer uma das reivindicações 1 a 13.