BRPI0810699B1

BRPI0810699B1 - método e aparelho de registro de fluxo de mídia em uma hint track de recepção de um arquivo de armazenamento multimídia

Info

Publication number: BRPI0810699B1
Application number: BRPI0810699-1A
Authority: BR
Inventors: Miska Hannuksela
Original assignee: Nokia Technologies Oy
Priority date: 2007-05-04
Filing date: 2008-05-02
Publication date: 2021-03-02
Also published as: KR20100028546A; JP2010526468A; EP2145270A2; KR101107815B1; CA2684851A1; CA2684851C; TW200901761A; JP5130352B2; AP2923A; US20080275905A1; MX2009011873A; RU2434277C2; EP2145270B1; WO2008135932A2; WO2008135932A3; BRPI0810699A2; AP2009005050A0; US8078644B2; TWI500325B; CN101675435A

Abstract

REGISTRO DE FLUXO DE MÍDIA EM UMA HINT TRACK DE RECEPÇÃO DE UM ARQUIVO DE ARMAZENAMENTO MULTIMÍDIA É mostrado um método para o armazenamento de fluxos de mídia em tempo real em um arquivo de armazenamento multimídia (1200). O conteúdo de mídia é gravado em um arquivo de acordo com um formato de arquivo que forneça instruções para a construção de pacotes de mídia. Pelo menos um pacote de mídia recebido é representado no arquivo usando as instruções para a construção de pacotes de mídia. Pelo menos um dos pacotes de mídia recebidos no arquivo também é associado com uma indicação de que ele pode conter erros. Esta tecnologia gera a vantagem de que os pacotes incorretamente transmitidos são fáceis de detectar, o que pode ser utilizado para evitar uma falha do dispositivo de reprodução.

Description

[001] CAMPO DE INVENÇÃO

[002] A presente invenção diz respeito, de forma geral, ao formato de arquivos de armazenamento multimídia. De maneira mais especifica, a presente invenção diz respeito ao uso e processamento da recepção de hint tracks no formato de arquivos de armazenamento multimídia.

[003] HISTÓRICO DA INVENÇÃO

[004] Esta seção tem como objetivo proporcionar um cenário ou contexto para a invenção que é relatada nas reivindicações.

[005] Esta descrição pode incluir conceitos que possam ser desenvolvidos, mas não necessariamente aqueles que já tenham sido previamente concebidos ou desenvolvidos.

[006] Portanto, a não ser que seja indicado de outra forma, o que é descrito nesta seção não é arte anterior à descrição e às reivindicações nesta solicitação e não é considerado como arte anterior por estar incluída nesta seção.

[007] O formato de arquivo de armazenamento multimídia é um elemento importante na cadeia de produção, manipulação, transmissão e consumo de conteúdo multimídia. Neste contexto, o formato de codificação (isto é, o formato de fluxo básico) diz respeito à ação de um algoritmo de codificação que codifique a informação contida em um fluxo de bits. O formato de arquivo de armazenamento compreende mecanismos para organizar os fluxos de bits gerados de tal forma que eles possam ser acessados para codificação local e execução, transferidos como arquivos, ou fluxos, todos utilizando uma variedade de arquiteturas de transporte e armazenamento. O formato de arquivo de armazenamento também pode facilitar a troca e edição da mídia, bem como o registro de fluxos em tempo real em um arquivo. Como tal, existem diferenças substanciais entre o formato de codificação e o formato de arquivo de armazenamento. A hierarquia de formatos de arquivos multimídia é descrita de maneira geral em 1000 na Figura 1.

[008] O formato de fluxo básico 1 100 representa um fluxo único, independente. Arquivos de áudio tais como arquivos amr e aac são construídos de acordo com o formato de fluxo básico. O formato de arquivo de armazenamento 1200 é um formato que pode conter ambos fluxos de áudio e vídeo em apenas um arquivo. Um exemplo de uma família de formatos de arquivo de armazenamento 1200 é baseada no formato de arquivo de mídia base ISO. Logo abaixo do formato de arquivo de armazenamento 1200 na hierarquia 1000 está o formato de multiplexação 1300. O formato de multiplexação 1300 é geralmente menos flexível e mais compacto do que um arquivo de áudio/vídeo (AV) construído de acordo com o formato de arquivo de armazenamento 1200. Os arquivos construídos de acordo com o formato de multiplexação 1300 são usados, geralmente, apenas com o objetivo de execução. Um fluxo de programa Moving Picture Experts Group (MPEG) - 2 é um exemplo de um fluxo construído de acordo com o formato de multiplexação 1300. O formato de idioma de apresentação 1400 é usado para finalidades como layout, interatividade, a sincronização de AV e discrete media, etc. Synchronized multimídia integration language (SMIL) e scalable vídeo graphics (SVG), ambos especificados pelo World Wide Web Consortium (W3C), são exemplos de um formato de idioma de apresentação 1400, o formato de arquivo de apresentação 1500 é caracterizado por conter todas as partes da apresentação no mesmo arquivo. Exemplos de objetos construídos de acordo com o formato de arquivo de apresentação são arquivos PowerPoint e arquivos conforme o perfil de apresentação estendido de formato 3GP.

[009] A mídia e os padrões de formato de arquivo de armazenamento disponíveis incluem o formato de arquivo de mídia base ISO (ISO/IEC 14496/12), o formato de arquivo MPEG-4 (ISO/IEC 14496-14), também conhecido como formato MP4), o formato de arquivo Advanced Video Coding (AVC) (ISO/IEC 14496-15) e o formato de arquivo 3GPP (3GPP TS 26.244, também conhecido como formato 3GP). Existe também um projeto em MPEG para o desenvolvimento do formato de arquivo scalable video coding (SVC), que pode tornar-se um complemento para o formato de arquivo advanced video coding (AVC). Em um esforço paralelo, MPEG está definindo um formato de hint track para a oferta de arquivos através de transporte unidirecional (file delivery over unidirectional transport - FLUTE) e sessões de código estratificado sincronizado (asynchronous layered coding - ALC), que irão tornar-se um complemento para o formato de arquivo de mídia base ISO.

[010] A organização Digital Video Broadcasting (DVB) está atualmente em processo de definição do formato de arquivo DVB. O objetivo primário da definição do formato de arquivo DVB é facilitar e interoperabilidade de conteúdo entre implementações das tecnologias DVB, tais como conversores STB de acordo com os atuais (DVT-T, DVB-C, DVB-S) e futuros padrões DVB, receptores de televisão Internet Protocol (IP), e receptores de televisão móveis de acordo com o DVB-Handheld (DVB-H) e suas evoluções futuras. O formato de arquivo DVB irá permitir a troca de mídia registrada (somente-leitura) entre dispositivos de diferentes fabricantes, a troca de conteúdo usando memórias de massa USB ou dispositivos similares de leitura/gravação e acesso compartilhado a armazenamento em disco comum em uma rede residencial, bem como outras funcionalidades. O formato de arquivo de mídia base ISO é atualmente o mais forte candidato a ser a base para o desenvolvimento do formato de arquivo DVB. O formato de arquivo ISO é a base para a derivação de todos os formatos de arquivo de armazenamento acima mencionados (excluindo apenas o próprio formato de arquivo ISO) - Estes formatos de arquivo (incluindo o formato de arquivo ISO) são chamados as famílias ISO de formatos de arquivo. O bloco básico de construção do formato de arquivo de mídia de base ISO é chamado uma caixa. Cada caixa inclui um cabeçalho e um conjunto. O cabeçalho da caixa indica o tipo e tamanho dela em bytes. Uma caixa pode conter outra caixas, e o formato de arquivo ISO especifica quais tipos de caixas são permitidos em uma caixa de certo tipo. Além disso, algumas caixas são obrigatoriamente presentes em cada arquivo, enquanto outras são simplesmente opcionais. E ainda, para alguns tipos de caixas, podem existir mais caixas presentes em um arquivo.

[011] Portanto, o formato de arquivo de mídia de base ISO essencialmente especifica uma estrutura hierárquica de caixas.

[012] A Figura 2 mostra uma estrutura simplificada de acordo com o formato de arquivo de mídia de base ISO. De acordo com a família ISO de formatos de arquivos, um arquivo 200 inclui dados de mídia e metadados que estão contidos em caixas separadas, a caixa de dados de mídia (mdat) 210 e a caixa de filme (moov) 220, respectivamente. Para que um arquivo seja operável, ambas estas caixas devem estar presentes. A caixa de dados de mídia 210 contém frames de vídeo e áudio, que podem ser intercalados e ordenados no tempo. A caixa de filma 220 pode conter um ou mais tracks, e cada track fica em uma caixa de track 240. Para a apresentação de um tipo de mídia, geralmente um track é selecionado.

[013] Deve-se notar que o formato de arquivo de mídia de base ISO não limita uma apresentação para ser contida em apenas um arquivo. Na verdade, uma apresentação pode estar contida em vários arquivos. Neste cenário, um arquivo contém os metadados para a apresentação inteira. Este arquivo pode também conter todos os dados de mídia, nesse caso a apresentação está contida nela mesma. Os outros arquivos, se usados, não requerem formatação de acordo com o formato de arquivo de mídia de base ISO. Os outros arquivos são usados para conter dados de mídia, e eles também podem conter dados não utilizados de mídia ou outras informações.

[014] O formato de arquivo de mídia de base ISO está relacionado apenas à estrutura do arquivo que contém os metadados. O formato dos arquivos de dados de mídia é restringido pelo formato de arquivo de mídia de base ISO ou os seus formatos derivados apenas em que os dados de mídia nos arquivos de mídia devem ser formatados como especificado no formato de arquivo de mídia de base ISO ou os seus formatos derivados.

[015] Além de tracks com tempo, arquivos ISO podem conter quaisquer objetos binários sem tempo em uma meta caixa. A meta caixa pode ficar no nível superior do arquivo, em uma caixa de filme 220, e em uma caixa de track 240, mas no máximo uma meta caixa pode ocorrer em cada um dos níveis do arquivo, o nível do filme, ou o nível de track. A meta caixa deve conter uma caixa ‘hdlr’, indicando a estrutura ou formato dos conteúdos da caixa ‘meta’. A meta caixa pode conter qualquer número de itens binários que possam ser mencionados, e cada um dos itens binários pode ser associado com um nome de arquivo.

[016] Um arquivo pode ser compatível com mais de um formato da família ISO de formatos de arquivo e nem sempre é possível, portanto, falar em termos de um mesmo “tipo” ou “marca” para o arquivo. Todos os arquivos ISO contêm uma caixa de tipo indicando qual formato de arquivo especifica o “melhor uso” do arquivo e também um conjunto de outras especificações com as quais o arquivo está em conformidade.

[017] O formato que é o “melhor uso” do arquivo é mencionado como a marca principal do arquivo, enquanto outros formatos compatíveis são mencionados como marcas compatíveis.

[018] A presença de uma marca na lista de marcas compatíveis da caixa de tipo do arquivo constitui ambos requerimento e permissão. A presença é uma reivindicação na qual o arquivo conforme todos os requisitos daquela marca, e a presença também representa uma permissão para a potencial implementação de um leitor que apenas aquela marca leia o arquivo. Em geral, são precisos leitores para implementar todos os recursos documentados para uma marca, a menos que ocorra uma das seguintes possibilidades: 1. A mídia que os leitores estão utilizando não usa nem requer uma função. Por exemplo, vídeo I-frame não requer uma tabela de amostra sync, e se uma reordenação de composição não estiver sendo usada, então não é necessária nenhuma tabela de deslocamento de tempo de composição. De maneira semelhante, se não for necessária proteção de conteúdo, então não é necessário o suporte das estruturas de proteção de conteúdo. 2. Outra especificação com a qual o arquivo está em conformidade proíbe o uso de um recurso. Por exemplo, algumas especificações derivadas proíbem explicitamente o uso de fragmentos de filmes. 3. O contexto em que o produto opera indica que algumas estruturas não são relevantes. Por exemplo, estruturas de hint track são relevantes apenas para produtos que estejam preparando o conteúdo para fazer ou fazendo ofertas de arquivos (tais como streaming) para o protocolo em hint track.

[019] Leitores de arquivo implementando uma certa marca devem tentar ler arquivos que estejam marcados como compatíveis com aquela marca.

[020] Um hint track é um track especial que geralmente não contém dados de mídia. Ao contrário, um hint track contém instruções para o empacotamento de um ou mais tracks para entrega em um certo protocolo de comunicação. O processo de envio de pacotes é baseado no tempo, substancialmente idêntico ao display de dados baseados no tempo, e é, portanto, convenientemente descrito por um track. Devido à presença de hint tracks, a carga operacional de um transmissor pode ser simplesmente comparada a unidades de dados de protocolo de construção de transmissor das amostras de mídia sem hints.

[021] O formato de arquivo de mídia de base ISO contém a definição de hint track para Real-Time Protocol (RTP) e protocolos Secure Real-Time Transport Protocol (SRTP), e a próxima Complementação 2 do formato de arquivo de mídia de base ISO irá conter a definição de hint track para protocolos FLUTE e ALC. Um formato de hint track para fluxo de transporte (TS) MPEG-2 também pode ser especificado, por exemplo, como parte do Formato de Arquivo DVB.

[022] A caixa mdat descrita na Figura 2 contém amostras para tracks. Em não-hint tracks, uma amostra é um frame individual de vídeo, uma série vídeo frames contígua de tempo, ou uma seção comprimida de áudio contígua de tempo.

[023] Em hint tracks, uma amostra define a formação de um ou mais pacotes formatados de acordo com o protocolo de comunicação identificado no cabeçalho de hint track.

[024] Hint track herdam todas as características de tracks de mídia comuns, tais como tempo das amostras e indicação de amostras de sincronização. Amostras hint contêm instruções para ajudar um transmissor a compor pacotes para transmissão. Estas instruções podem conter dados imediatos para enviar (por exemplo, informação de cabeçalho) ou segmentos de referência dos dados de mídia, em outras palavras, as amostras de mídia em tracks de mídia não precisam ser copiadas nas amostras de hint tracks, ao invés disto, as amostras de hint apontam para as amostras de tracks de mídia. Portanto, os próprios dados de mídia não precisam ser reformatados de maneira alguma. Esta abordagem é mais eficiente em termos de espaço do que uma abordagem que requeira que a informação de mídia seja particionada nas unidades de dados atuais que serão transmitidas para um determinado transporte e formato de mídia. Em uma tal abordagem, a execução local requer ou a reunião da mídia dos pacotes ou, se houverem duas cópias da mídia - que uma seja para execução local e a outra para transporte. De maneira semelhante, a transmissão de tais mídias em múltiplos protocolos usando esta abordagem requer múltiplas cópias dos dados da mídia para cada protocolo de entrega.

[025] Isto é ineficaz em termos de espaço a menos que os dados de mídia tenham sido grandemente modificados para transporte (por exemplo, pela aplicação de técnicas de codificação corretoras de erros ou por encriptação).

[026] Se um arquivo ISO contiver hint tracks, os tracks de mídia que fizerem referência aos dados de mídia a partir dos quais as hints foram construídas permanece no arquivo, mesmo se os hint tracks não fizeram referência direta aos dados contidos nelas. Após excluir todos hint tracks, a apresentação inteira sem hints permanece.

[027] A Figura 3 é uma representação de um sistema de comunicações de vídeo geral. Devido ao fato de que vídeo descompactado requer uma enorme banda larga, o vídeo de entrada 300 é compactado por um codificador de fonte 305 para uma taxa de bits desejada. O codificador de fonte 305 pode ser dividido em dois componentes - um codificador de formato de onda 310 e um codificador de entropia 315. O codificador de formato de onda 310 faz a compactação de sinais de vídeo com perdas, enquanto o código de entropia 315 converte a saída do codificador de formato de onda 310 em uma sequência binária sem que ocorram perdas. Um codificador de transporte 320 encapsula o vídeo compactado de acordo com os protocolos de transporte em uso intercalando e modulando os dados, por exemplo. Os dados são transmitidos para o lado do receptor através de um canal de transmissão 325. O receptor faz operações inversas para obter sinal de vídeo reconstruído para a exibição. As operações inversas incluem o uso de um decodificador de transporte 330 e um decodificador de fonte 335 que pode ser dividido em um decodificador de entropia 340 e um decodificador de formato de onda 345, resultando em um vídeo de saída 350.

[028] A maioria dos canais de televisão está suscetível a erros de transmissão. Erros de transmissão podem ser, grosso modo, classificados em duas categorias - erros de bits (bit errors) e erros de apagamento (erasure errors). Erros de bits são causados por eventos físicos que ocorram no canal de transmissão, tais como ruídos e interferência. Pilhas de protocolos para transporte de mídia em tempo real oferecem geralmente mecanismos tais como códigos de verificação de redundância cíclica (cyclic redundancy check - CRC) para detectar erros de bits. É uma prática comum descartar conjuntos de protocolo errados no decodificador de transporte. Os desafios na decodificação de dados de vídeo errados encontra-se na possibilidade de erros de bits intermitentes, a detecção exata da posição do erro, e do variable length coding (VLC) usado pelo codificador de entropia. Devido à interferência de erros de bits, é provável que uma grande porção de um conjunto de protocolos não seria decodificável de qualquer forma, e portanto descartar o conjunto de protocolo inteiro não provoca muitas exclusões desnecessárias de dados. Os mecanismos de detecção de erros oferecidos pelos protocolos de comunicação tão geralmente capazes de produzir uma conclusão binária - ou o pacote está corrompido ou ele está correto. Depende, portanto, dos mecanismos de camadas de codificação de fonte determinar a localização exata dos erros. Apesar de existirem métodos baseados em violações sintáticas e semânticas e interrupções de textura não naturais para a detecção da localização de erros, a falsa detecção de erros de bits pode resultar em vídeos com perturbações. Devido ao comprimento variável de codificação, um único erro de bits possivelmente muda a interpretação da palavra código na qual ele ocorre e causa uma perda de sincronização de palavras código subsequentes. Mesmo que a sincronização de palavras código seja restabelecida, pode não ser possível determinar a localização espacial ou temporal dos dados decodificados. Quanto aos erros de apagamento (erasure errors), existem duas fontes primárias de tais erros. Primeiro, filas acumulam-se em elementos de rede congestionada, tais como roteadores, causando perdas de pacote. Segundo, o decodificador de transporte geralmente processa erros de bits removendo os pacotes inteiros nos quais os erros de bits ocorreram.

[029] Em geral, erros de transmissão devem ser primeiro detectados e então corrigidos ou encobertos pelo receptor.

[030] Como explicado acima, erros de bits são geralmente detectados usando códigos CRC ou similares e pacotes corrompidos são descartados. Protocolos de comunicação para transporte de mídia em tempo real geralmente anexam um número de sequência que é complementado por um para cada pacote transmitido, e portanto, perdas de pacote podem ser detectados de uma falha nos valores de número de sequência de pacotes consecutivos. A correção de erros refere-se à capacidade de recuperar dados com erros perfeitamente como se os erros nem mesmo tivessem ocorrido. O encobrimento de erros refere-se à capacidade de encobrir os impactos dos erros de transmissão de modo que eles possam ser visíveis apenas com dificuldade no vídeo reconstruído. Geralmente, uma quantidade de redundância é adicionada à fonte ou codificação de transporte para ajudar na detecção, correção, e encobrimento de erros.

[031] As técnicas de correção e o encobrimento de erros podem ser, grosso modo, classificadas em três categorias - encobrimento antecipado de erros, encobrimento de erros por pós-processamento e encobrimento de erros interativo. O encobrimento antecipado de erros refere-se aquelas técnicas nas quais o lado do transmissor adiciona tais redundâncias aos dados transmitidos de maneira que o receptor pode recuperar com facilidade os dados transmitidos mesmo se houvessem erros de transmissão. O encobrimento de erros por pós- processamento é totalmente orientado pelo receptor.

[032] Estes métodos tentam estimar a representação correta de dados recebidos com erros. O transmissor e o receptor também podem cooperar para minimizar o efeito de erros de transmissão. Estes métodos utilizam grandemente as informações de feedback dados pelo receptor. O encobrimento de erros por pós-processamento também é chamado de encobrimento passivo de erros, enquanto as outras duas categorias representam formas de encobrimento ativo de erros.

[033] Uma classificação ortogonal de algoritmos de correção e encobrimento de erros, comparada à categorização apresentada acima, é baseada na camada da pilha de protocolo na qual opera o algoritmo em questão. Os métodos na camada física podem, por exemplo, usar a modulação de maneira inteligente ou intercalar bits de dados para serem transmitidos na camada de link, blocos de dados recebidos com erros podem ser retransmitidos de maneira seletiva, por exemplo. Em geral, os métodos envolvendo o codificador ou decodificador da fonte são mencionados como correção de erros atenta à mídia e algoritmos de encobrimento, enquanto os métodos que operam apenas no codificador e decodificador de transporte são independentes de mídia. Os métodos que requeiram a interoperação de várias camadas de pilhas de protocolo encaixam-se na categoria de algoritmos de otimização camada cruzada. O termo “Codificação fonte-canal (Joint source-channel coding)” é usado quando a codificação de fonte e transporte opera sem costuras para lidar com erros de transmissão em esforço conjunto.

[034] Para muitas aplicações de comunicação multimídia em tempo real, é desejável não ter um arquivo de multimídia transmitido como arquivo, mas, ao invés disto, ter os dados de mídia encapsulados em pacotes de um protocolo de comunicação. Além disso, é desejável ainda que os media players sejam capazes de analisar, decodificar, e executar qualquer arquivo multimídia que seja gerado de fluxos de mídia recebidos. Se qualquer arquivo multimídia gravado puder ser executado pelos media players existentes, os media players não precisarão ser atualizados ou trocados.

[035] A maioria dos formatos de arquivo de armazenamento, se não todos eles, tem como objetivo a execução de arquivos sem erros que sejam transmitidos de maneira confiável para o dispositivo de execução e/ou oferecer conteúdo de mídia para a transmissão via streaming ou outros dispositivos de envio. Consequentemente, os formatos de arquivo de armazenamento não oferecem mecanismos para a indicação de erros de transmissão, e não há garantias de que os media players existentes serão capazes de lidar com fluxos de mídia com erros de forma satisfatória. Ao invés disso, tais players podem travar ou responder de outras formas inesperadas. Seria, portanto, desejável que os arquivos gerados de fluxos de mídia recebidos fossem executados com os media players existentes e compatíveis com os formatos de arquivo existentes. Além disso, seria ainda desejável no caso de players e decodificadores sofisticados, que fossem incluídos mecanismos para o encobrimento eficaz de erros de transmissão de fluxos que sejam gravados em um arquivo.

[036] Tem havido várias abordagens convencionais para atingir pelo menos um dos aspectos identificados acima. Em uma primeira abordagem, o fluxo de transporte recebido está incluído como tal no arquivo, ou o fluxo de transporte está armazenado em um arquivo separado, e este arquivo separado é referido pelo arquivo de apresentação (isto é, o arquivo contendo os metadados). Nesta disposição, o fluxo de transporte refere-se à camada de pilha de protocolo mais baixa que é considerada relevante na aplicação. Para transmissão de mídia baseada em RTP, o fluxo de transporte geralmente refere-se a um fluxo de pacotes RTP. Quando fluxos de mídia básicos estiverem encapsulados em um fluxo de transporte MPEG-2 (como em DVB-T, DVB-C, e DVB-S), o fluxo de transporte refere-se ao fluxo de transporte MPEG-2. Na estrutura de formato de arquivo de mídia de base ISO, o fluxo de transporte pode ser incluído como uma única amostra em uma track de mídia. Assim os fluxos de transporte MPEG-2 são incluídos em arquivos QuickTime.

[037] Metadados específicos para o fluxo de transporte podem ser armazenados em uma nova estrutura de formato de arquivo; no formato de arquivo de mídia de base ISO, a estrutura pode estar na meta box.

[038] Em uma segunda abordagem, o fluxo de transporte recebido é convertido em tracks de dados básicos. Metadados específicos para o fluxo de transporte podem ser armazenados em uma nova estrutura de formato de arquivo; no formato de arquivo de mídia de base ISO, a estrutura pode estar na meta box.

[039] Em uma terceira abordagem, os pacotes de dados recebidos de um fluxo são gravados como uma hint track do arquivo que é gravado. Porém, o uso de uma hint track não é uma solução logicamente válida, uma vez que hint tracks oferecem instruções de compartimentação para um servidor ou, de forma mais geral, para o envio. E ainda, uma hint track gravada pode não oferecer um fluxo válido a ser reenviado.

[040] Por exemplo, números de sequência RTP devem ser contínuos em um fluxo transmitido, mas em um fluxo gravado um pacote que esteja faltando causa uma descontinuidade em números de sequência RTP.

[041] O fato de que a moov box pode ser completada apenas após todos os dados de mídia serem recebidos faz com que seja impossível fazer gravações contínuas para um único arquivo na segunda e na terceira abordagens discutidas acima. Este problema pode ser evitado quando o recurso de fragmento de filme é usado para segmentar o arquivo gravado como descrito na Solicitação de Patente nos Estados Unidos No. 1 1/292,786, protocolada em 1 de dezembro de 2005. De maneira alternativa, os dados de mídia dos fluxos recebidos pode ser registrado em arquivos separados comparados com os meta dados. Porém, de execuções com mudança de tempo no arquivo a ser gravado forem desejadas, então os fragmentos de vídeo conforme descrito na Solicitação de Patente nos Estados Unidos No. 1 1/292,786 devem ser usados.

[042] RESUMO DA INVENÇÃO

[043] Várias configurações da presente invenção oferecem um sistema e um método para o recebimento de um fluxo de pacote de mídia e gravação do conteúdo de mídia. O conteúdo de mídia é gravado em um arquivo de acordo com um formato de arquivo que ofereça instruções para a construção de pacotes de mídia. Pelo menos um pacote de mídia recebido é representado no arquivo usando as instruções para a construção de pacotes de mídia. Pelo menos um dos pacotes de mídia recebidos no arquivo também é associado com uma indicação de que ele pode conter erros.

[044] Várias configurações da presente invenção oferecem um mecanismo compatível com retroativo para armazenar fluxos de mídia em tempo real em um arquivo de armazenamento multimídia. Na prática, isto significa que os players existentes podem executar corretamente as partes que podem ser recuperáveis dos fluxos recebidos. A identificação e localização de erros de transmissão nos fluxos recebidos é ativada, e os players sofisticados podem, portanto, encobrir de forma eficiente erros de transmissão. Além disso, várias configurações da presente invenção contribuem para evitar a duplicação de quaisquer dados de mídia em um arquivo gravado. Várias configurações da presente invenção podem ser usadas em conjunção com virtualmente todos receptores que gravem o formato de arquivo DVB.

[045] Estas e outras vantagens e características da invenção, juntamente com sua organização e forma de operação, se tornarão aparentes pela seguinte descrição detalhada quando consideradas em conjunto com os desenhos que acompanham, nos quais elementos iguais possuem numerais iguais nos diversos desenhos descritos abaixo.

[046] BREVE DESCRIÇÃO DOS DESENHOS

[047] A Figura 1 é uma descrição da hierarquia de formatos de arquivo multimídia;

[048] A Figura 2 é uma representação de uma estrutura simplificada de um arquivo ISO;

[049] A Figura 3 é uma representação de um sistema geral de comunicações de vídeo;

[050] A Figura 4 é uma representação e um sistema genérico de comunicações multimídia para o uso com várias configurações da presente invenção;

[051] A Figura 5 é um fluxograma mostrando a operação de uma versão simplificada de um receptor de acordo com várias configurações da presente invenção;

[052] A Figura 6 é uma vista em perspectiva de um dispositivo eletrônico que pode ser usado em conjunção com a implementação de várias configurações da presente invenção, e

[053] A Figura 7 é uma representação esquemática do circuito que pode ser incluído no dispositivo eletrônico da Figura 6.

[054] DESCRIÇÃO DETALHADA DAS VÁRIAS CONFIGURAÇÕES

[055] Várias configurações da presente invenção oferecem um sistema e um método para o recebimento de um fluxo de pacote de mídia e gravação do conteúdo de mídia. O conteúdo de mídia é gravado em um arquivo de acordo com um formato de arquivo que ofereça instruções para a construção de pacotes de mídia. Pelo menos um pacote de mídia recebido é representado no arquivo usando as instruções para a construção de pacotes de mídia. Pelo menos um dos pacotes de mídia recebidos no arquivo também é associado com uma indicação de que ele pode conter erros.

[056] De acordo com uma configuração da presente invenção, os fluxos são gravados em uma ou mais hint tracks de um formato de arquivo, e é indicado especialmente na hint track que a hint track é gerada de fluxos recebidos. As hint tracks correspondem precisamente aos fluxos recebidos e, portanto, oferecem um media player com todo um mecanismo para lidar com erros de transmissão da forma mais eficiente possível. Por exemplo, a amostra de estrutura (isto é, a estrutura de pacote) das hint tracks contém o número de sequência do pacote, a partir do qual um pacote que esteja faltando pode ser identificado se as estruturas de hint track RTP do formato de arquivo de mídia de base ISO foram reutilizadas para as hint tracks de recepção de várias configurações da presente invenção, o número de sequência residiria no elemento de sintaxe sequenciada RTP da estrutura de dados de pacote RTP.

[057] De acordo com uma segunda configuração da presente invenção, fluxos recebidos são convertidos em tracks de mídia válidas, isto é, tais tracks podem ser decodificadas sem detecção de erro de transmissão não padronizada e mecanismos de lidar com erros.

[058] A criação de tracks de mídia válidas garante que os media players existentes possam executar o arquivo gravado. Uma ou mais hint tracks específicas também são criadas. Sempre que possível, uma amostra de hint contém referências às amostras das media players ao invés de uma cópia do conjunto de pacotes, com isto reduzindo os requisitos de espaço para armazenamento para o arquivo. A criação de um track de mídia válida pode, algumas vezes, causar a omissão de alguns grupos de pacotes. Por exemplo, quando uma gravura de referência em um fluxo de vídeo codificado é perdida, a track de mídia deve pular quaisquer figuras diretamente ou indiretamente previstas da figura de referência perdida.

[059] Uma amostra de hint pode, portanto, conter uma cópia de um conjunto de pacotes que não esteja presente na track de mídia correspondente.

[060] A Figura 4 é uma representação gráfica de um sistema de comunicação multimídia genérico dentro do qual várias configurações da presente invenção podem ser implementadas.

[061] Conforme mostrado na figura 4, uma fonte de dados 100 fornece um sinal fonte em um formato analógico, digital não comprimido ou digital comprimido ou qualquer combinação desses formatos. Um codificador 110 codifica o sinal da fonte em um fluxo de bits de mídia codificados. Deve-se notar que um fluxo de mídia a ser decodificado pode ser recebido de forma direta ou indireta pelo dispositivo remoto localizado virtualmente dentro de qualquer tipo de rede. Além disso, o fluxo de bits pode ser recebido de um hardware ou software local. O codificador 110 pode ser capaz de codificar mais do que um tipo de mídia, como áudio e vídeo ou mais do que um codificador 110 pode ser necessário para codificar tipos diferentes de mídia do sinal forte. O decodificador 110 pode também receber entradas produzidas sinteticamente, tais como gráficos e texto, ou ele pode ser capaz de produzir fluxos de bits codificados de mídia sintética. A seguir, apenas o processamento de um fluxo de bits de mídia codificado de um tipo de mídia será considerado para simplificar a descrição. Deve-se notar, porém, que geralmente os serviços transmitidos em tempo real compreendem vários fluxos (geralmente pelo menos um fluxo de áudio, um de video e texto de legenda). Também deve ser notado que o sistema pode incluir muitos codificadores, mas na Figura 4 apenas um codificador 110 está representado para simplificar a descrição sem que haja uma falta de generalidade. Além de tudo isto, deve-se entender ainda que, apesar do texto e dos exemplos contidos aqui poderem descrever especificamente um processo de codificação, um especialista no assunto entenderia que os mesmos conceitos e princípios também seriam aplicáveis ao processo correspondente de decodificação e vice-versa.

[062] O fluxo de bits de mídia codificado é transferido para um armazenamento 120. O armazenamento 120 pode compreender qualquer tipo de memória de massa para armazenar o fluxo de bits de mídia codificado. O formato do fluxo de bits de mídia codificado no armazenamento 120 pode ser um formato de fluxo de bits básico contido em si mesmo, ou um ou mais fluxos de bits de mídia codificados podem ser encapsulados em um arquivo de armazenamento. Alguns sistemas operam “ao vivo”, isto é omitem armazenamento e fluxo de bits de mídia codificados do codificar 110 diretamente para o transmissor 130. O fluxo de bits de mídia codificado é então transferido para o transmissor 130, também chamado de servidor, de acordo com a necessidade. O formato usado na transmissão pode ser um formato de fluxo de bits básico contido em si mesmo, um formato de fluxo de pacote, ou um ou mais fluxos de mídia codificados podem ser encapsulados em um arquivo de armazenamento. O codificador 110, o armazenamento 120 e o servidor 130 podem ficar em um mesmo dispositivo físico ou podem ser incluídos em dispositivos separados. O codificador 110 e o servidor 130 podem operar com conteúdo energizado em tempo real, em cujo caso o fluxo de bits da mídia codificado geralmente não é armazenado permanentemente, mas protegido por períodos curtos de tempo no codificador 110 de conteúdo e/ou no servidor 130 para suavizar as variações no atraso de processo, atraso de transferência e na taxa de bits da mídia codificada.

[063] O servidor 130 envia o fluxo de bits de mídia codificados usando uma pilha de protocolos de comunicação. A pilha pode incluir, mas não se limita a, Protocolo RTP (Real-Time Transport Protocol), Protocolo UDO (User Datagram Protocol) e Protocolo da Internet (IP). Quando a pilha de protocolos de comunicação é orientada para o pacote, o servidor 130 encapsula o fluxo de bits de mídia codificados em pacotes.

[064] Por exemplo, quando o RTP é usado, o servidor 130 encapsula o fluxo de bits de mídia codificado em pacotes RTP de acordo com um formato de conjuntos RTP. Geralmente, cada tipo de mídia tem um formato de pacote RTP dedicado a ele.

[065] Deve-se notar, novamente, que um sistema pode conter mais do que um servidor 130, mas por uma questão de simplicidade, a descrição a seguir considera apenas um servidor 130.

[066] O servidor 130 pode estar conectado, ou não, a um gateway 140 através de uma rede de comunicação. O gateway 140 pode fazer diferentes tipos de funções, tais como a tradução de um fluxo de pacote de acordo com uma pilha de protocolo de comunicação para outra pilha de protocolo de comunicação, misturando e reparando fluxos de dados, e manipulação de fluxos de dados de acordo com capacidades de downlink e/ou receptor, tais como controlar a taxa de bits do fluxo daí em diante para de acordo com as condições de rede downlink prevalecentes. Exemplos de gateways 140 incluem multipoint conference control units (MCUs), gateways entre telefonia de vídeo em circuito e pacote, servidores Push-to-talk por Celular (PoC), encapsuladores IP em sistemas de digital video broadcasting-handheld (DVB-H), ou conversores de STB que encaminham transmissões locais para redes em fios residenciais. Quando o RTP é usado, o gateway 140 é chamado de RTP mixer ou um tradutor RTP e atua geralmente como um ponto de extremidade de uma conexão RTP.

[067] O sistema inclui um ou mais receptores 150, tipicamente capaz de receber, desmodular, e desencapsular o sinal transmitido em um fluxo de bits de mídia codificados. O fluxo de bits de mídia codificados é transferido para uma armazenagem de gravação 155. A armazenagem de gravação 155 pode compreender qualquer tipo de memória de massa para armazenar o fluxo de mídia codificado. A armazenagem de gravação 155 pode de maneira alternativa ou adicional compreender memória de computação, tal como memória de acesso aleatório. O formato de fluxo de bits de mídia codificados na armazenagem de gravação 155 pode ser um formato de fluxo básico de bits contido, ou um ou mais fluxos de bits de mídia codificados podem ser encapsulados em um arquivo de armazenamento. Se houverem muitos fluxos de bits de mídia codificados, tais como um fluxo de áudio e um fluxo de vídeo, associados um com o outro, um arquivo de armazenamento é geralmente usado e o receptor 150 compreende ou está anexado a um gerador de arquivo de armazenamento produzindo um arquivo de armazenamento de fluxos de entrada. Alguns sistemas operam “energizados”, isto é, omitem a armazenagem de gravação 155 e transferem fluxos de bits de mídia codificados do receptor 150 diretamente para o decodificador 160. Em alguns sistemas, apenas a parte mais recente, do fluxo gravado, por exemplo, o excerto de 10 minutos mais recente do fluxo gravado, é mantido na armazenagem de gravação 155, enquanto qualquer dado gravado anteriormente é descartado da armazenagem de gravação 155.

[068] O fluxo de bits de mídia codificado é transferido da armazenagem de gravação 155 para o decodificador 160. Se existirem muitos fluxos de mídia codificados, tais como um fluxo de áudio e um fluxo de vídeo, associados um ao outro e encapsulados em um arquivo de armazenamento, um analisador de arquivo (não mostrado na figura) é usado para desencapsular cada fluxo de mídia codificado do arquivo de armazenamento. A armazenagem de gravação 155 ou um decodificador 160 podem compreender o analisador de arquivo, ou o analisador de arquivo é anexado ou à armazenagem de gravação 155 ou ao decodificador 160.

[069] O fluxo de bits de mídia de codificação/decodificação [codec] geralmente é processado posteriormente por um decodificador 160, cuja saída é um ou mais fluxos de mídia não comprimidos. Finalmente, um processador 170 pode reproduzir os fluxos de mídia não comprimidos com um alto-falante ou uma tela, por exemplo. O receptor 150, a armazenagem de gravação 155, o decodificador 160, e o processador 170 podem ficar em um mesmo dispositivo físico ou eles podem ser incluídos em dispositivos separados.

[070] A seguir encontra-se uma implementação de como indicar hint tracks gravadas no formato de arquivo de mídia de base ISO.

[071] Nessa implementação, as hint tracks gravadas são indicadas com um tipo de entrada de amostra que é diferente da entrada de amostra correspondente planejada para hint tracks do servidor. Por exemplo, hint tracks RTP para o servidor são hint tracks (manipulador de mídia “hint”), com um formato de entrada na descrição de amostra de “rtp”. Uma hint track RTP gravada está com o formato de entrada “rrtp” na descrição de amostra. Ambas entradas de amostra são especificadas de maneira idêntica à seguinte: class RtpHintSampleEntry ( ) extends SampleEntry (‘rtp’) { uint (16) hinttrackversion = 1; uint (16) highestcompatibleversion = 1; uint (32) maxpacketsize; box additionaldata [ ]; } class ReceivedRtpHintSampleEntry ( ) extends SampleEntry (‘rrtp’) { uint (16) hinttrackversion =1; uint (16) highestcompatibleversion = 1; uint (32) maxpacketsize; box additional data [ ]; }

[072] Um par de formatos de entradas de amostras gravadas e do servidor é especificado para cada protocolo ao qual pode ser adicionada uma hint, tal como um fluxo de transporte (transport stream - TS) SRTP e MPEG-2. A amostra de hint pode ser especificada de maneira idêntica para cada par de formatos de hint track do servidor e gravada para qualquer protocolo. Definição idêntica do formato de amostra de hint em cada par de formatos de hint tracks do servidor e gravadas para qualquer protocolo pode, por exemplo, reduzir o tamanho de uma implementação de software em linhas de termos de código de uma linhagem de programação ou número de instruções executáveis pela máquina. Porém, também pode ser benéfico especificar o formato de amostra para a hint track gravada diferentemente comparado ao formato de hint track do servidor do mesmo protocolo. Por exemplo, pode não ser razoável incluir o campo continuity_counter do cabeçalho do pacote MPEG-2 TS para o formato de amostra de hint do servidor, como os servidores devem simplesmente incrementar o valor em 1 (no módulo aritmético) por cada um dos pacotes transmitidos. Porém, o campo contador de continuidade é necessário para o formato de amostra de hint gravada, como perdas de pacote podem ser resultantes de uma falha nos valores do contador de continuidade de pacotes subsequentes recebidos. Além disso, pode ser razoável especificar formatos de hint tracks em uma camada de pilha de protocolo diferente da camada usada na hint track do servidor. Por exemplo, se uma amostra de hint corresponde a um pacote de Internet Protocol (IP), um analisador de arquivo poderia usar a verificação do número de bits que estão sendo transferidos do cabeçalho do User Datagram Protocol (UDP) para constatar a presença de erros de bits no pacote recebido, isto é, a integridade do pacote recebido. De maneira alternativa ou complementar, a amostra de hint gravada pode conter campos que não estejam presentes no formato de pacote correspondente. Tais campos podem ser usados para transportar informações das camadas subjacentes de pilhas de protocolos, por exemplo. Um exemplo de tal campo pode ser um campo indicador de erros de bits para uma amostra de hint RTP gravada. O receptor pode definir o campo indicador de erro de bits baseado na verificação do número de bits UDP que estão sendo transferidos ou em qualquer código CRC ou verificações de número de bits presentes em qualquer camada subjacente de pilha de protocolo.

[073] A Figura 5 é um fluxograma mostrando a operação de uma versão simplificada de um receptor de acordo com as várias configurações da presente invenção. Porém, deve-se notar que o receptor pode aceitar várias formas e configurações.

[074] O processo da Figura 5 começa com o pacote de transporte sendo levado em 510 do buffer do destinatário para pacotes de transporte recebidos. Além disso, o pacote de transporte é gravado em um segundo buffer, aqui mencionado como um buffer de pacote de curto prazo. O pacote de transporte pode compreender um pacote RTP, um pacote de fluxo de transporte MPEG-2, ou um pacote de qualquer outro protocolo de transporte. Em 520, a continuidade da numeração da sequência de pacote é verificada, com a determinação sendo feita como se houvesse uma falha na sequência de numeração.

[075] Se os pacotes de transporte estiverem formatados de acordo com RTP, o número de sequência (sequence number - SN) fica no cabeçalho RTP. Se os pacotes de transporte estiverem formatados de acordo com um fluxo de transporte MPEG-2, o número de sequência é chamado continuity_counter e fica no cabeçalho do pacote TS.

[076] Se não houver falhas na sequência da numeração e nenhum dos pacotes no buffer de pacotes de curto prazo forem identificados como contendo erros de bits, então em 530 existe uma verificação se o pacote atual contém os últimos bytes do conjunto para o frame de vídeo ou, de maneira mais generalizada, para uma unidade de acesso de vídeo para a qual os pacotes estejam atualmente armazenados no buffer de pacote de curto prazo. Na maior parte dos conjuntos RTP de vídeo o bit M do cabeçalho RTP é especificado para indicar que o pacote contém os últimos bytes do conjunto para o frame de vídeo codificado. Outra forma de detectar o último pacote de um frame de vídeo é verificar o timestamp RTP do próximo pacote. Se o timestamp RTP for diferente do timestamp RTP atual, então o pacote atual contém os últimos bytes do conjunto do frame de vídeo codificado atual.

[077] Quando o encapsulamento em fluxo de transporte MPEG-2 estiver em uso, um valor de unidade de conjunto start_indicator igual a 1 no próximo pacote de fluxo de transporte indica que o pacote TS contém os últimos bytes do conjunto do frame de vídeo codificado atual se o pacote atual for o último pacote de um frame de vídeo, o processo retorna a 510. Deve-se notar que os processos 520 e 530 operam apenas se a ordem de transmissão for idêntica à ordem de decodificação dos dados de vídeo codificados. A detecção de perda e fim de frame para ordem de transmissão intercalada requer geralmente uma análise de unidades de dados recebidas. Um exemplo de detecção de perda para transmissão intercalada de vídeo H 264/AVC é oferecido na seção 8 da Recomendação Técnica 3GPP 26 946 (6- edição), “Multimedia Broadcast/Multicast Service, User service guidelines”. A detecção de limites de frames é especificada na seção 7 4 1 2 4 de H 264/AVC (isto é, ITU-T Recommendation H 264).

[078] De maneira adicional, observa-se que a discussão acima com referência à Figura 5 é descrita em termos de um fluxo de vídeo. Áudio geralmente não é previsto temporalmente por um número de frames, e de forma usual todo frame de áudio está incluído em um pacote de transporte. Consequentemente, a parte do processo acima que diz respeito à procura de um próximo frame de acesso aleatório pode, de maneira usual, ser omitido em fluxos de áudio. Além disso, se um frame de áudio sempre couber no pacote de transporte, gravando, o processo 530 pode ser omitido e a etapa 540 pode ser modificada para substituir frames de áudio que estejam faltando com frames vazios na gravação de amostras de áudio no arquivo.

[079] Se o pacote atual de um frame de vídeo codificado, então uma amostra de vídeo é derivada dos conjuntos de pacotes coletados no buffer de pacote de curto prazo em 540. O processo de derivação pode compreender uma simples concatenação dos conjuntos de pacotes. A amostra de vídeo gerada é, então, gravada em um arquivo. Deve-se notar que, devido aos metadados (moov box ou moof box) que geralmente precedem os dados de mídia em ordem de aparecimento, a amostra de vídeo pode ser gravada em um arquivo temporário primeiro e copiada para o arquivo atual sendo criada uma vez que todos os metadados correspondentes estejam completos.

[080] Em 550, uma amostra de hint é gerada de cada um dos pacotes armazenados no buffer de pacote de curto prazo. Como a amostra de vídeo gerada em 540 já contém os dados de vídeo codificados, as amostras de hint simplesmente referem-se à track de vídeo, à amostra de vídeo gerada e à faixa de bytes apropriada dentro da amostra de vídeo. Quando as amostras de hint forem geradas para todos os pacotes no buffet de pacote de curto prazo, o buffet é esvaziado e o processo retorna a 510.

[081] Se uma falha na sequência de numeração do pacote ou um erro de bits em qualquer um dos pacotes no buffer de pacote de curto prazo for detectado em 520, então uma amostra de hint é gerada de cada um dos pacotes armazenados no buffer de pacotes de curto prazo em 560. Porém, como os conjuntos de pacotes no buffer de pacote de curto prazo não são isentos de erros, nenhuma amostra de vídeo é gerada na track de vídeo. Assim, os conjuntos de pacotes são essencialmente incluídos nas amostras de hint usando ou o mecanismo de construção imediata ou o mecanismo de hint track “fat”.

[082] Quando construtores imediatos forem usados, uma cópia dos dados do conjunto é incluída nas instruções de compartimentação. Quando uma hint track “fat” está sendo usada, os conjuntos de pacotes são incluídos na seção mdat para a hint track e são mencionados dos construtores da hint track. Quando amostras de hint foram geradas para todos os pacotes no buffer de pacote de curto prazo, o buffer é esvaziado.

[083] Após 560, o próximo pacote é obtido do buffer do destinatário em para pacotes de transporte em 570. O próximo pacote será, então, examinado para determinar se o pacote inicia um frame de vídeo codificado oferecendo um ponto de acesso aleatório para o fluxo. O início de um frame de vídeo codificado pode ser detectado de acordo com o processo 530. A detecção de um ponto de acesso aleatório depende do formato de vídeo e do seu formato de conjunto.

[084] Por exemplo, em H 264/ AVC, o frame de independent decoding refresh (IDR) pode ser identificado pelo cabeçalho da unidade network abstraction layer (NAL), que é facilmente acessível do conjunto de pacotes. Outro mecanismo de indicação de ponto de acesso aleatório fornecido por H.264/AVC é o ponto de recuperação da mensagem supplemental enhancement information (SEI), que pode indicar tipos diferentes de posições de acesso aleatórios graduais. Outro exemplo de indicações de ponto de acesso aleatório está incluído no formato de conjunto RTP para o codec VC-I, que inclui uma sinalização específica para este objetivo se um ponto de acesso aleatório for indicado, o processo continua em 530. Caso contrário, o processo continua em 560.

[085] Deve-se notar que o processo descrito acima pode ser implementado de várias formas. Por exemplo, não é possível que tracks de mídia sejam criadas durante o processo de recepção, apenas se as hint tracks forem criadas para o arquivo. As media tracks podem, então, ser criadas off-line, após a recepção dos fluxos ser terminada. Durante a geração off-line tracks de mídia, as amostras de hint (contendo os dados do conjunto de mídia) podem ou não serem modificadas para referirem-se aos dados nas amostras para tracks de mídia. Com relação à Figura 4, a geração off-line de tracks de mídia resultaria em dois blocos adicionais que receberiam as suas entradas de armazenagem de gravação 155 e produzindo para o decodificador 160. O primeiro bloco na ordem de processamento pode ser mencionado como um regravador de arquivo, que recebe um arquivo contendo apenas as hint tracks (sem a presença de tracks de mídia) e dá saída aos arquivos com as tracks de mídia. O segundo bloco na ordem de processamento pode ser mencionado como uma segunda armazenagem de gravação, que pode ter propriedades semelhantes à armazenagem de gravação 155.

[086] Outra implementação envolve a gravação para um formato intermediário durante a recepção. O formato intermediário pode compreender um formato de armazenagem simples para os pacotes recebidos. Por exemplo, um fluxo de transporte MPEG-2 pode ser armazenado desta maneira em um arquivo, e pacotes RTP podem ser armazenados quando algum framing indicando o tamanho dos pacotes também é incluído no arquivo. O arquivo de acordo com o formato intermediário pode posteriormente ser convertido em um formato de arquivo estruturado, tal como uma versão ou derivado do formato de arquivo de base ISO. Durante o processo de conversão, uma operação semelhante à descrita acima pode ser usada. Com relação à Figura 4, esta implementação iria requerer dois blocos adicionais recebendo entradas da armazenagem de gravação 155 e dando saída ao decodificador 160. O primeiro bloco em ordem de processamento pode ser mencionado como um regravador de arquivo, que dá entrada a um arquivo de acordo com o formato intermediário e dá saída ao arquivo de acordo com um formato de arquivo mais estruturado. O segundo bloco na ordem de processamento pode ser mencionado como uma segunda armazenagem de gravação, que pode ter propriedades semelhantes à armazenagem de gravação 155.

[087] O regravador de arquivo e a segunda armazenagem de gravação mencionados acima podem ficar no mesmo dispositivo que o receptor 150, a armazenagem de gravação 155, o decodificador 160 ou em outro dispositivo. E ainda, o regravador de arquivo e a segunda armazenagem de gravação podem ficar no mesmo dispositivo ou em dispositivos diferentes.

[088] Um analisador de arquivo incluído no, ou anexado ao decodificador 160 e o decodificador 160 podem operar como se um arquivo comum estivesse sendo analisado e decodificado, isto é, como se as tracks de mídia e amostras de mídia fossem analisadas e decodificadas, enquanto as hint tracks e amostras de hint são omitidas. De maneira alternativa, o analisador de arquivo e o decodificador 160 podem operar como se um fluxo de bits de mídia codificado fosse recebido em tempo real, em outras palavras, o analisador de arquivo pode construir pacotes de acordo com as instruções nas amostras de hint e passar os pacotes para o decodificador 160. Além disso, o ritmo com o qual os pacotes são passados para o decodificador 160 pode corresponder à programação dos pacotes. O formato dos pacotes pode ser idêntico aos pacotes transmitidos pelo transmissor 130, ou ele pode incluir essencialmente os mesmos pedaços de informação que os pacotes transmitidos pelo transmissor, potencialmente acompanhados com dados de pilhas de protocolos subjacentes. O decodificador 160 detecta pacotes com partes faltando ou corrompidos como descritos acima com referência à Figura 5. O decodificador 160 pode responder à pacotes com partes faltando ou corrompidos aplicando encobrimento de erros ou algoritmos de rastreamento de erros. E ainda, o decodificador pode pedir a recuperação ou encobrimento dos pacotes com partes faltando ou corrompidos com um protocolo de feedback de um transmissor 130. Outras disposições do analisador de arquivo e do decodificador 160 também são possíveis. Por exemplo, o decodificador 160 pode concluir se um pacote é corretamente ou incorretamente decodificado se os seus dados estão contidos em uma amostra de mídia de uma track de mídia ou em uma amostra de mídia, respectivamente.

[089] Também se deve notar que uma hint track pode conter um ou mais fluxos/tipos de mídia e também pode conter metadados associados. Por exemplo, se arquivos de áudio e vídeo são carregados como fluxos básicos através de um fluxo de transporte MPEG-2, os arquivos de áudio e vídeo podem ser gravados na mesma hint track. E ainda, a sinalização específica MPEG-2 também pode ser incluída na mesma hint track.

[090] Ainda se deve notar que existem sistemas de criptografia/DRM que operam no domínio de transporte, isto é, que podem criptografar pacotes ou conjuntos de pacotes independentemente ou como um fluxo de pacotes em contraste com frames de mídia codificados, por exemplo. Se os direitos de uso DRM fornecidos proibirem o armazenamento do conteúdo em formato decifrado, então o destinatário não reproduz as tracks de mídia, ao invés disto, apenas armazenar os pacotes recebidos na hint track especial.

[091] Dispositivos de comunicação incorporando e implementando várias configurações da presente invenção podem comunicar-se usando várias tecnologias de transmissão incluindo, mas não se limitando a, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.1 1, etc. Um dispositivo de comunicação envolvido na implementação de várias configurações da presente invenção podem comunicar-se usando várias mídias incluindo, mas não se limitando a, rádio, infravermelhas, laser, conexão a cabo e similares.

[092] As figuras 6 e 7 mostram um dispositivo eletrônico 12 representativo, no qual a presente invenção pode ser implementada. Deve-se entender, porém, que a presente invenção não foi planejada para ser limitada a um tipo particular de dispositivo eletrônico 12. O dispositivo eletrônico 12 das Figuras 6 e 7 inclui uma estrutura 30, um monitor 32 em forma de uma tela de cristal líquido, um teclado 34, um microfone 36, uma peça auricular 38, uma bateria 40, uma porta infravermelha 42, uma antena 44, um smart card 46 em forma de um UICC de acordo com uma configuração da invenção, um leitor de cartão 48, interface de rádio do circuito 52, circuito de codec 54, um controle 56, uma memória 58 e uma bateria SO. Circuitos individuais e elementos são todos de um tipo bem conhecido no mercado, por exemplo, a linha Nokia de telefones celulares.

[093] As várias configurações da presente invenção descritas aqui são descritas no contexto geral dos passos ou processos do método, os quais podem ser implementados em uma configuração por um produto de programa de computador, configurado em uma mídia de leitura em computador, incluindo instruções para execução em computador, como código do programa, executado por computadores em ambientes de rede. Geralmente, módulos de programa podem incluir rotinas, programas, objetos, componentes, estruturas de dados, etc. que executem tarefas particulares ou implementem tipos de dados abstratos específicos.

[094] Instruções executáveis em computador, estruturas de dados associados e módulos de programas representam exemplos de códigos de programas para execução de passos dos métodos mostrados aqui. A sequência específica de tais instruções executáveis ou estruturas de dados associados representa exemplos de atos correspondentes para implementação das funções descritas em tais passos ou processos.

[095] Implementação em software e na web das várias configurações da presente invenção podem ser obtidas com técnicas de programação padrão com lógica baseada em regras e outras lógicas para obter vários processos ou etapas de busca em bancos de dados, processos ou etapas de correlação, processos ou etapas de comparação e processos ou etapas de decisão. Deve-se notar que as palavras “componente” e “módulo”, como são utilizadas aqui e nas seguintes requisições, têm a intenção de abranger implementações que utilizem uma ou mais linhas de código de software, e/ou implementações de hardware, e/ou equipamento para o recebimento de entradas manuais.

[096] A descrição supra das configurações da presente invenção é apresentada por motivos de ilustração e descrição. A descrição anterior não se propõe a ser exaustiva ou a limitar as configurações da presente invenção precisamente à forma mostrada, e modificações e variações são possíveis sob a luz dos ensinamentos acima mencionados ou dos ensinamentos que podem ser adquiridos na prática com as várias configurações da presente invenção. As configurações discutidas aqui foram escolhidas e descritas com o objetivo de explicar os princípios e a natureza das várias configurações da presente invenção e a sua aplicação prática para permitir a uma pessoa, já familiarizada com os conhecimentos da área, utilizar a presente invenção nas suas várias configurações e com as várias modificações que sejam adequadas ao uso particular contemplado.

Claims

1. Um método, compreendendo: receber (150) um fluxo de pacotes de mídia incluindo conteúdo de mídia; e gravar (155) o conteúdo de mídia em um arquivo de acordo com um formato de arquivo que forneça instruções para a construção de pacotes de mídia, em que pelo menos um pacote de mídia no fluxo de pacote de mídia recebido é representado no arquivo utilizando as instruções para a construção de pacotes de mídia, sendo o referido método caracterizado por: em que as instruções para construir os pacotes de mídia estão incluídas em hint samples de pelo menos uma hint track, e em que pelo menos um pacote de mídia recebido no arquivo está associado a uma indicação de que pelo menos um pacote de mídia recebido contém erros de transmissão; em que cada hint sample representando os pacotes de mídia indica que o conteúdo da mídia contém erros de transmissão.

2. Método, de acordo com a reivindicação 1, caracterizado por o hint sample compreender uma indicação de perda de transmissão de pelo menos um pacote no fluxo de pacote de mídia.

3. Método, de acordo com a reivindicação 1, caracterizado por os erros de transmissão representarem pelo menos um dos erros de bit e perdas de pacotes durante a transmissão do fluxo de pacotes de mídia.

4. Um aparelho, compreendendo: meios para receber (150) um fluxo de pacotes de mídia incluindo conteúdo de mídia; e meios para gravar (155) o conteúdo de mídia em um arquivo de acordo com um formato de arquivo que forneça instruções para construir pacotes de mídia, em que pelo menos um pacote de mídia no fluxo de pacotes de mídia recebidos é representado no arquivo utilizando as instruções para construir pacotes de mídia, sendo o referido aparelho caracterizado por: as instruções para construir os pacotes de mídia estarem incluídas em hint samples de pelo menos uma hint track, e em que pelo menos um pacote de mídia recebido no arquivo está associado a uma indicação de que pelo menos um pacote de mídia recebido contém erros de transmissão; cada hint sample representando os pacotes de mídia indicar que o conteúdo da mídia contém erros de transmissão.

5. Aparelho, de acordo com a reivindicação 4, caracterizado por o hint sample compreender uma indicação de perda de transmissão de pelo menos um pacote.

6. Aparelho, de acordo com a reivindicação 4, caracterizado por os erros de transmissão representarem pelo menos um dos erros de bit e perdas de pacotes durante a transmissão do fluxo de pacotes de mídia.