BRPI0008604B1 - Processos para converter um fluxo de dados de entrada, e para reproduzir um programa audiovisual gravado, e, aparelho - Google Patents

Processos para converter um fluxo de dados de entrada, e para reproduzir um programa audiovisual gravado, e, aparelho Download PDF

Info

Publication number
BRPI0008604B1
BRPI0008604B1 BRPI0008604-5A BR0008604A BRPI0008604B1 BR PI0008604 B1 BRPI0008604 B1 BR PI0008604B1 BR 0008604 A BR0008604 A BR 0008604A BR PI0008604 B1 BRPI0008604 B1 BR PI0008604B1
Authority
BR
Brazil
Prior art keywords
stream
data
format
elementary
transport
Prior art date
Application number
BRPI0008604-5A
Other languages
English (en)
Other versions
BR0008604A (pt
Inventor
Octavius J Morris
Original Assignee
Koninkl Philips Nv
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninkl Philips Nv filed Critical Koninkl Philips Nv
Publication of BR0008604A publication Critical patent/BR0008604A/pt
Publication of BRPI0008604B1 publication Critical patent/BRPI0008604B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor
    • H04N5/92Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4344Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/3027Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording used signal is digitally coded
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147PVR [Personal Video Recorder]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/90Tape-like record carriers
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/107Programmed access in sequence to addressed parts of tracks of operating record carriers of operating tapes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/765Interface circuits between an apparatus for recording and another apparatus
    • H04N5/775Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Television Signal Processing For Recording (AREA)
  • Television Systems (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Time-Division Multiplex Systems (AREA)

Description

"PROCESSOS PARA CONVERTER UM FLUXO DE DADOS DE ENTRADA, E PARA REPRODUZIR UM PROGRAMA AUDIO VISUAL GRAVADO, E, APARELHO" A presente invenção relaciona-se a processus e aparelhos para converter fluxos de dados multiplexados de um formato multiplexado para outro (transmultiplexação). A invenção encontra aplicação particular, por exemplo, na transmultiplexação de fluxos de vídeo e áudio a partir de um formato de fluxo de programa para o formato de fluxo de transporte, de acordo com a especificação MPEG-2 (ITU-T Recommendation H.222.0 | ISO/IEC 13818-1). O Padrão MPEG-2 mencionado acima especifica métodos genéricos para multiplexação de multimídia, sincronização e recuperação de base de tempo. As especificações provêm uma multiplexação de multimídia baseada em pacote, onde cada fluxo de bit elementar (vídeo, áudio, outros dados) é segmentado em um Fluxo Elementar Empacotado (PES), e então os pacotes respectivos são multiplexados em dois tipos de fluxos distintos. Fluxo de Programa (PS) é um multiplex de pacotes PES de extensão variável e projetado para uso em ambientes livres de erro, tal como gravação em disco. Fluxo de Transporte (TS) consiste de pacotes de extensão fixa de 188 bytes, possui funcionalidade de multiplexação de programa múltiplo, bem como multiplexação de vários pacotes PES de um programa, que é processado para uso em ambientes sujeitos a erros, tal como a rádio difusão. A sincronização de multimídia e recuperação de base de tempo são obtidas pelo uso de marcações de tempo para relógio de tempo de sistema e apresentação/decodificação.
Como cada tipo de fluxo possui suas vantagens e desvantagens em diferentes circunstâncias, a especificação MPEG-2 reconhece que a conversão entre os dois formatos pode ser desejável.
Entretanto, devido a diferenças entre os formatos e particularmente os modelos "decodificador alvo" que definem a restrições, tais como tamanhos de meio de armazenamento temporário, retardos de tempo, taxas de dados e assim por diante, os diferentes fluxos elementares não podem ser programados em um formato, do mesmo modo que se fossem de outro. E necessário portanto desmultiplexar e remultiplexar os dados de fluxo elementar ao converter de um tipo de fluxo para o outro. É também o fator daquela informação de sistema que coloca uma estrutura nos dados PS projetados para acesso randômico, edição e similar, que está geralmente ausente da rádio difusão TS. EP-A-0 833 514 (Sony) propõe um sistema de aparelho gravador/reprodutor e apresentação (aparelho de visualização). O reprodutor, por exemplo, lê dados de formato PS a partir de um disco e os converte para o formato TS para visualização. Por outro lado, o tamanho de meio de armazenamento temporário nas realizações desta não aparecem como considerando as diferentes restrições e que requerem reprogramação dos diferentes fluxos elementares, para converter um formato PS válido para um formato TS válido. De fato, pode ser mostrado que as restrições impostas pela própria especificação TS requerem um meio de armazenamento temporário para pelo menos uma informação do segundo valor de vídeo, e o mesmo esforço de processamento de que seria requerido para fazer o fluxo a partir da linha de partida. É um objeto da invenção reduzir o esforço computacional e/ou o espaço de armazenamento requerido, ao converter fluxos de dados entre formatos tais como o fluxo de programa MPEG e fluxo de transporte. Será entendido que a invenção é aplicável além dos limites estritos dos sistemas de acordo com MPEG-2, pois problemas similares surgiríam em geral ao converter fluxos multiplexados entre quaisquer dois formatos.
Os inventores reconheceram que, embora a reprogramação seja inevitável para converter de um formato para o outro, as restrições inerentes do formato fonte podem ser exploradas para reduzir o tamanho do armazenamento temporário, e/ou a quantidade de processamento requerida na conversão. A invenção provê um processo para converter um fluxo de dados de entrada possuindo um formato de Fluxo de Programa (PS) em um fluxo de dados de saída possuindo um formato de Fluxo de Transporte (TS), o processo compreendendo: (a) ler, a partir do citado fluxo de dados de entrada, blocos de dados e sucessivos blocos de dados, citados fluxos de dados de entrada incluindo dados do primeiro e segundo fluxos de dados elementares, formados e multiplexados de acordo com um modelo de decodificador PS; (b) acumular os dados do primeiro e segundo fluxos elementares, respectivamente na primeira e segunda estruturas de fila; (c) estabelecer um modelo de decodificador alvo TS incluindo primeiro e segundo meios de armazenamento temporário e hipotéticos para o primeiro e segundo fluxos elementares, respectivamente; (d) gerar uma sucessão de pacotes de transporte para formar citado fluxo de dados de saída, transportando citados primeiro e segundo fluxos de dados no citado formato TS, com referência ao citado modelo decodificador alvo; e (e) atualizar o estado dos citados primeiro e segundo meios de armazenamento temporário hipotéticos, dentro do citado decodificador alvo TS, em resposta a cada pacote de transporte gerado e propriedades predeterminadas do citado modelo de decodificador; onde cada pacote de transporte compreende dados a partir de cada uma dentre a primeira fila, a segunda fila ou nenhuma fila, dependendo da programação dos citados fluxos elementares dentre do fluxo de dados de entrada e no estado dos citados primeiro e segundo meios de armazenamento temporário e dentro do citado modelo de decodifícador alvo TS, e onde o processo inclui inibir a leitura de um bloco de dados adicional a partir do citado fluxo quando, na ausência de uma vaga para dados do citado segundo fluxo elementar dentro do modelo decodifícador alvo, uma referência de relógio do citado fluxo de dados de entrada avança além de uma referência de relógio e do citado fluxo de dados de saída, de um limiar de espera predeterminado. A invenção provê adicionalmente um método onde o formato PS em pelo menos os citados primeiro e segundo fluxos elementares de dados tenham sido codificados, divididos em pacotes de fluxo elementar com cabeçalhos de pacote, e o total de pacotes intercalados, enquanto no formato TS tais pacotes de fluxo elementar são adicionalmente subdivididos em diversos pacotes de transporte menores, e os pacotes de transporte do primeiro e segundo fluxos elementares intercalados com cada outro e com pacotes de transporte transportando dados a partir de nenhum fluxo.
Em realizações da invenção descritas aqui, a subdivisão de cada fluxo elementar em pacotes de fluxo elementar é a mesma nos fluxos de entrada e saída.
Em realizações da invenção, o fluxo de dados de formato TS pode ser de taxa de dados constantes, citados pacotes de transporte sendo de tamanho e período uniforme.
Em realizações da invenção, o fluxo de entrada pode ser lido em blocos, cada bloco contendo pelo menos um pacote de fluxo elementar inteiro, e somente pacotes do fluxo elementar.
Em realizações da invenção, cada bloco pode conter um código de tempo de entrega PS, um código de tempo de transporte e sendo avançado com a geração de cada pacote de transporte e sendo sincronizado inicialmente com o código de tempo de entrega PS.
Em uma realização da invenção, os formatos PS e TS definem restrições como: (i) diferença de tempo máxima (desvio) entre tempos de entrega para respectivas unidades de apresentação, no primeiro e segundo fluxos elementares, possuindo um tempo de apresentação comum; e pelo menos um dentre: (ii) capacidade de armazenamento temporário de dados para cada fluxo elementar entre entrega e decodificação; e (iii) taxa de entrega de dados de cada fluxo elementar na escala de uma unidade de acesso, a partir do fluxo de transporte para um meio de armazenamento temporário para decodificação.
Em uma realização particular, a restrição do meio de armazenamento temporário (ii) é mais estrita no formato TS do que no formato PS para o segundo fluxo elementar, e citado limiar de espera é suficiente para acomodar uma quantidade de dados em excesso, correspondendo à diferença entre o que pode ser acomodado dentro do meio de armazenamento temporário no decodificador alvo PS e o que pode ser acomodado no decodificador alvo TS.
Em uma outra realização, citada restrição de taxa mínima (iii) é mais restrita no formato TS do que no formato PS para o segundo fluxo elementar, e citado limiar de espera é suficiente para permitir tempo extra para transporte de uma unidade de acesso dentro do segundo fluxo elementar, o tempo extra correspondendo à diferença entre o tempo mais curto possível de entrega de tal unidade de acesso dentro da restrição de formato PS e o tempo mais longo possível para entrega na mesma unidade de acesso dentro da restrição de formato TS.
Os formatos PS e TS podem permitir que parâmetros de codificação diferentes sejam implementados no citado segundo fluxo elementar, de modo a variar uma ou ambas quantidades de dados a serem entregues e o período de apresentação para cada unidade de acesso, enquanto citado limiar de espera é fixo de acordo com um tempo extra máximo requerido entre os parâmetros de codificação permitidos.
Em realizações específicas da invenção descrita aqui, o limiar de espera pode ser menos de um quinto do desvio permitido no fluxo do programa.
Em uma realização particular, a unidade de acesso compreende um quadro de áudio comprimido. A invenção provê adicionalmente um processo para remultiplexar primeiro e segundo fluxos elementares de dados, de modo a gerar um fluxo contínuo de pacotes de transporte de acordo com uma segundo modelo de decodificador alvo predeterminado, os dados dos citados primeiro e segundo fluxos tendo sido previamente multiplexados de acordo com um primeiro modelo diferente de decodificador alvo predeterminado, onde citados dados são restritos com referência ao progresso na remultiplexação do segundo fluxo elementar, independente de uma vaga para dados do primeiro fluxo no segundo modelo de decodificador alvo, desde que citada leitura seja julgada suficientemente adiantada no progresso e na remultiplexação do segundo fluxo elementar, para compensar quanto a diferenças no primeiro e segundo modelos de decodificador alvo.
Em uma realização da invenção, cada um dos primeiro e segundo modelos de decodificador alvo define para cada fluxo elementar o respectivo meio de armazenamento temporário de tamanho finito para dados a serem decodificados, e onde, pelo menos para o segundo fluxo elementar, o meio de armazenamento temporário é menor no decodificador alvo TS do que no decodificador alvo PS.
Em uma realização da invenção, a taxa de dados média do primeiro fluxo elementar é substancialmente maior que aquela do segundo fluxo elementar.
Em realizações particulares descritas aqui, os dados do primeiro fluxo elementar compreendem figuras de vídeo codificadas e os dados do segundo fluxo elementar compreendem quadros de áudio codificados. A invenção provê adicionalmente processos para converter um fluxo de dados de entrada possuindo um formato de Fluxo de Programa (PS) em um fluxo de dados de saída possuindo um Fluxo de Transporte (TS) onde o formato TS é de acordo com a especificação de Fluxo de Transporte MPEG-2, enquanto o citado formato PS é de acordo com a especificação de Fluxo de Programa MPEG-2, ambas conforme definido na Recomendação ITU-T H.222.0 e ISO/IEC 13818.1. A invenção provê um processo reproduzindo um programa audiovisual gravado, onde um fluxo de dados no formato PS é lido a partir de um canal de dados, convertido para um formato TS por um processo conforme descrito acima e alimentado através de um canal adicional para um decodificador compatível TS.
Em uma realização da invenção, o canal compreende uma gravação do citado fluxo de dados de entrada em uma portadora de gravação. A invenção provê adicionalmente aparelho compreendendo meio adaptado especificamente para implementar qualquer dos processos de acordo com a invenção relatados acima. Tal aparelho pode, por exemplo, fazer parte de um aparelho decodificador independente (conversor set-top box), um aparelho de apresentação (tal como um aparelho de TV) o um aparelho de gravação e reprodução (VCR digital).
Outras características e vantagens da invenção, além daquelas identificadas acima, e muitas variações e modificações na mesma invenção tomar-se-ão claras ao leitor especializado, a partir de uma consideração da seguinte descrição das realizações específicas.
BREVE DESCRICÂO DOS DESENHOS
Realizações da invenção serão agora descritas, somente a título de exemplo, por referência aos desenhos que a acompanham, nos quais Figura 1 ilustra um exemplo de sistema de entretenimento de vídeo digital no qual uma realização da invenção é aplicada;
Figura 2 ilustra o formato de dados em um fluxo de transporte de formato (TS);
Figura 3 ilustra o formato de dados em um formato de fluxo de programa;
Figura 4 mostra os caminhos de dados chave e blocos funcionais na conversão de um sinal de formato PS para formato TS, de acordo com uma realização da invenção;
Figura 5 ilustra um processo de programação hipotético que não explora o conhecimento das restrições de fluxo de entrada;
Figura 6 ilustra um processo de programação de acordo com uma realização da invenção. DESCRIÇÃO DETALHADA DAS REALIZAÇÕES Exemplo de Sistema Figura 1 ilustra um exemplo de sistema de entretenimento de vídeo digital doméstico, incluindo um sintonizador de TV digital 100, um "conversor set-top box" 102 para decodificar sinais de vídeo digital, controlar o acesso a canais pagos e assim por diante, um dispositivo digital de reprodução e gravação de vídeo 104, tal como um sistema de vídeo de disco ótico bem conhecido ou futuro gravador DVR, e o próprio meio de armazenamento (disco 106). Neste exemplo, um conjunto de TV analógico convencional 108 é usado nesta configuração para exibir imagens de um satélite, cabo ou rádio difusão terrestre, ou de uma gravação do disco 106. Entre o sintonizador digital 100 e o conversor set-top box 102, sinais de formato de fluxo de transporte compatível MPEG (TS) levam um número de canais de TV digital, alguns dos quais podem ser misturados para decodificação com arranjos de acesso condicional especial (TV paga). Os formatos de rádio difusão digital padrão, por exemplo, DVB, ATSC e ARIB, são aplicações específicas dentro do formato de fluxo de transporte MPEG-2. O conversor set-top box 102 decodifica também um programa desejado de dentro do fluxo de transporte TS, para prover sinais analógicos de áudio e vídeo ao conjunto de TV. Estes sinais analógicos podem, naturalmente, ser gravados por um gravador de vídeo convencional (VCR). Por outro lado, para a qualidade e funcionalidade máxima, o gravador direto digital para digital, tal como o bem conhecido sistema de vídeo disco óptico ou gravador DVR 104 é preferido. Este é conectado ao conversor set-top box via uma interface digital tal como IEEE 1394 (“Firewire”). Esta transporta um TS parcial, no qual o programa selecionado é separado do multiplex TS maior, e é apresentado ainda dentro do formato TS. Por outro lado, para tirar vantagem da estrutura de diretório melhorada e características de acesso randômico, o reprodutor/gravador 104 é arranjado para converter o formato TS em formato PS, para gravar no disco 106, e para converter fluxos de formato PS gravados no disco 106 em formato TS parcial para reprodução, via interface digital e conversor set-top box 102, no TV 108. A presente descrição é relacionada primariamente ao processo de conversão a partir do formato de Fluxo de Programa (PS) para Fluxo de Transporte (TS), enquanto a conversão na outra direção é assunto de nosso pedido pendente atual intitulado “Method and Apparatus for Converting Data Streams” e reivindicando prioridade a partir do pedido de patente do Reino Unido No. 9930788.6, depositado em 30 de Dezembro de 1999 (PHB 34446). Antes de examinar em detalhe as técnicas aplicadas para conversão eficiente entre estes formatos, os dois formatos serão descritos em mais detalhe com referência às figuras 2 e 3.
Formato de Fluxo de Transporte (TS) Figura 2 ilustra as características chave e estrutura do formato do Fluxo de Transporte (TS) MPEG-2. O Fluxo de Transporte (TS) é um fluxo contínuo de pacotes de transporte rotulados T-PKT no desenho, cada um compreendendo 188 bytes de dados, e possuindo formato mostrado no topo da figura. Detalhes completos do Fluxo de Transporte MPEG-2, incluindo Sintaxe, semântica e restrições aplicáveis, será encontrado na Recomendação ITU-T H.262 | ISO/IEC 13818-2. Informação sobre o sistema MPEG-2 está disponível online em http://www.mpeg.org. Brevemente, cada pacote de transporte inclui uma porção de cabeçalho e uma porção de carga útil, a carga útil sendo indicada como bytes DAT-0 a DAT-N na figura. O cabeçalho começa com um byte de sincronização distintiva SYNC seguido de várias marcações e campos de controle, incluindo um indicador de erro de transporte TEI, um indicador de partida de unidade de carga útil USI, um indicador de prioridade de transporte TPI, uma identificação de pacote PID, campo de controle de mistura de transporte TSC, controle de campo de adaptação AFC e contador de continuidade CC. Dependendo do conteúdo do campo AFC, pode estar presente um campo de adaptação AF, ocupando alguns dos espaços alocados a dados de carga útil.
No exemplo do formato de rádio difusão digital DVB, a taxa de dados do Fluxo TS é em tomo de 40 Mbits/s, enquanto a taxa de dados típica para um programa visual de áudio é de menos de 10 Mbits/s. Consequentemente, conforme mostrado em TS na figura 2, vários programas PROG1, PROG3 podem ser multiplexados em um único fluxo de transporte. O campo PID de cada pacote de transporte indica um fluxo elementar ao qual o pacote se relaciona, estes sendo intercalados em unidades de pacotes de transporte com plenitude de outros fluxos. Um programa pode, por exemplo, compreender um fluxo de vídeo (PID=’005’ no exemplo), um fluxo de áudio (PID=’006’) e fluxo de dados de tele texto (PID=’007’). A correspondência entre valores PID e programas, e o tipo de dados transportados com cada PID é mantido na forma de tabelas de informação específica de programa (PSI). Periodicamente, dentro do fluxo de transporte, uma tabela de associação de programa PAT é transportada em um fluxo especial de pacotes de transporte com PID=0. A PAT, por sua vez, indica para PR0G1, PROG3, etc., qual fluxo transporta uma tabela de mapeamento de programa PMT, que lista completamente os diferentes valores PID relacionados ao programa único, e descreve o conteúdo de cada um (vídeo, áudio, áudio de linguagem alternativa, etc.). Estas tabelas e outros dados para fins de controle são referidos aqui como informação de sistema.
Para reproduzir ou gravar um dado programa (PROG1) a partir do fluxo de transporte, a carga útil DAT-0 a DAT-N de pacotes de transporte sucessivos tendo aquela PID, é concatenada em um fluxo, e este fluxo transporta pacotes de fluxo elementar empacotados PES-PKT, que são adicionalmente definidos na especificação MPEG-2. Cada pacote PES começa com um prefixo de código de partida de pacote distintivo PSCP. A seguir, no cabeçalho de pacote PES está um identificador de fluxo SID que identifica o tipo de fluxo elementar (por exemplo, de vídeo, áudio, fluxo de preenchimento, ou fluxo privado). Pacotes PES não possuem uma extensão fixa, a menos que especificado em uma aplicação particular, e um campo de extensão de pacote PES, LEN, especifica o número de bytes no pacote PES. Vários campos de controle e marcação C&F então se seguem, incluindo, por exemplo, um indicador de alinhamento de dados DAI em um campo de extensão de cabeçalho HLEN. Vários campos opcionais estão presentes dentro do cabeçalho HDAT, dependendo do valor de marcações associadas no campo C&F, por exemplo, uma marcação de tempo de apresentação PTS pode estar presente, especificando o tempo com referência a um relógio sistema no qual uma "unidade de apresentação" (imagem, quadro de áudio etc.) começando no pacote PES presente deve ser apresentada. Em certos casos, as unidades de apresentação são decodificada sem uma ordem diferente de sua ordem de apresentação, em cujo caso uma marcação de tempo de decodificação pode também estar presente. A carga útil PY-0 a PY-N de pacotes PES sucessivos, tendo o mesmo SID, forma um fluxo elementar contínuo de dados, mostrado esquematicamente em ES na figura 2. No caso de um fluxo elementar de vídeo ES-VIDEO, várias sequências de imagem de clips SEQ estão presentes, cada uma incluindo em sua partida um cabeçalho de seqüência SEQH. Vários parâmetros o decodificador, incluindo matrizes de quantização, tamanhos de meio de armazenamento temporário e similares, são especificados no cabeçalho da seqüência. Consequentemente, a reprodução correta do fluxo de vídeo pode somente ser obtida começando o decodificador na localização de um cabeçalho de seqüência. Dentro dos dados para cada ffeqüência estão uma ou mais "unidades de acesso" dos dados de vídeo, cada uma correspondendo a uma imagem (campo ou quadro, dependendo da aplicação). Cada imagem é precedida de um código de início de imagem PSC. Um grupo de imagens GOP pode ser precedido de um código de início de grupo GSC, todos seguindo um cabeçalho de seqüência particular SEQH.
Como é bem conhecido, imagens MPEG-2 e outros formatos digitais modernos são codificadas por referência uma à outra, de modo a reduzir a redundância temporal. A compensação de movimento provê uma estimativa do conteúdo de uma imagem a partir do conteúdo já decodificado de uma imagem ou imagens vizinhas. Portanto, um grupo de imagens GOP pode compreender: um quadro “I” intra-codificado, que é codificado sem referência a outras imagens; imagens codificadas “P” (preditivas) que são codificadas usando vetores de movimento baseados em um quadro I precedente; e imagens bidirecionais previstas “B”, que são codificadas/previsão a partir de quadros I e/ou P, antes e depois delas na seqüência. A quantidade de dados requeridos para uma imagem B é menor que aquela requerida para uma imagem P, que por sua vez é menor que aquela requerida para uma imagem I. Por outro lado, uma vez que imagens P e B são codificadas somente com referência às outras imagens, somente as imagens I provêm um ponto de entrada real para começar a reprodução de uma dada seqüência. Adicionalmente, será notado que os dados GO, as imagens I e P são codificadas antes das imagens correspondentes B, e então reordenadas após decodificação, de modo a obter a ordem de apresentação correta. Consequentemente, imagens B e P são exemplos em que a marcação de tempo da apresentação PTS e marcação de tempo de decodificação DTS podem diferir.
Finalmente, na figura 2 é mostrada uma representação de um fluxo elementar de áudio ES-AUDIO. Este compreende quadros simples de dados FRI, com códigos de início de quadro. Vários formatos de áudio são permitidos, variando em termos de taxa de amostragem (32 kHz, 48 kHz e etc.) e também taxa de dados (por exemplo, 32 kbit por segundo, ou variável). Estas e outras propriedades dos fluxos de áudio e vídeo são codificadas na informação específica de programa PSI e nos cabeçalhos de pacote PES.
Quadros de áudio e imagens de vídeo possuindo a mesma marcação de tempo de apresentação PTS são aqueles que devem ser apresentados simultaneamente na saída do decodificador. Por outro lado, existe grande liberdade na programação dos pacotes de dados a partir dos diferentes fluxos elementares, de tal modo que as unidades de acesso de áudio e vídeo possuindo o mesmo valor BTS podem chegar no fluxo de transporte TS afastadas de até 1 segundo.
Formato de Fluxo de Programa (PS) Figura 3 ilustra os outros tipos de formatos principais especificados para sinais MPEG-2, o fluxo de programa (PS). Mostrado no topo da figura, PS conduz os mesmos fluxos elementares ES-VIDEO e ES-AUDIO como fluxo de transporte ilustrado na figura 2, e novamente na forma de pacotes PES, PES-PKT. O fluxo de programa não é tão finamente dividido e empacotado como TS, e geralmente transporta somente os fluxos requeridos para uma única apresentação. Os pacotes PES inteiros PES PKT são empacotados em grupos de um ou mais nos pacotes de fluxo de programa PACK, com um cabeçalho básico compreendendo um código de partida de pacote distintivo PSC, uma marcação de tempo de referência de relógio de sistema SCR e uma indicação PMR programme_mux_rate, que é a taxa de bit na qual o fluxo de programa PS pretende ser apresentado a um decodificador. Um programme_mux_rate típico, por exemplo na especificação de sistema de vídeo disco ótico bem conhecida, é de 10,08 Mbits/s. Opcionalmente, um pacote de fluxo de programa inclui enchimento STF e um cabeçalho de sistema SYSH. Conforme ilustrado no topo da figura 3, antes que quaisquer pacotes de vídeo V ou pacotes de fluxo de áudio Al, A2, etc. sejam transmitidos, o fluxo de programa começa com um cabeçalho de sistema extensivo, especificando vários parâmetros da codificação e dos decodificadores, um diretório de cabeçalhos de seqüência de suas posições, por exemplo, em um disco ou outro meio de armazenamento e transportando fluxo de programa, no sentido do decodificador ser ajustado adequadamente para a decodificação de um programa específico. Uma vez que não há estrutura de pacote de transporte com códigos PID, o identificador de fluxo SID nos pacotes PES do fluxo de programa especifica o tipo de fluxo elementar transportado no dado pacote PES, e também, se necessário, com um dos diversos fluxos daquele tipo (áudio 1, áudio 2, etc.), de tal modo que aqueles corretos podem ser encontrados e apresentados ao decodificador. A informação de sistema no cabeçalho de sistema SYSH provê descrição adicional.
Aplicações, tais como sistema de vídeo disco ótico bem conhecido, especificam que cada pacote no fluxo de programa transporta somente pacotes PES de um fluxo de programa, e realmente apenas um único pacote PES é transportado por pacote, tipicamente. No caso de armazenamento em um disco ótico ou meio de gravação similar, cada pacote PES corresponde geralmente a uma unidade de recuperação ou ''setor'' da estrutura de preenchimento de disco. Em geral, o padrão MPEG-2 permite que diferentes tipos e números de pacotes PES sejam misturados dentro de cada “pack”, e o tamanho do “pack” pode ser permitido variar em outras aplicações.
Decodificadores Alvo de Sistema No sentido de assegurar que o armazenamento temporário e outros aspectos de um decodificador real são capazes de decodificar cada tipo de fluxo sem quebras no presente programa audiovisual, o padrão MPEG-2 especifica um modelo de fluxo de transporte, "decodificador alvo de sistema" (T-STD) e um modelo de decodificador alvo de sistema de fluxo de programa (P-STD). Amplamente, cada decodificador alvo de sistema é um modelo de um decodificador real hipotético tendo meios para desmultiplexar os diferentes fluxos elementares do formato TS ou PS, possuindo decodificadores para cada um dos tipos de dados de áudio, vídeo e controle de sistema, e possuindo meios de armazenamento temporário entre o fluxo que entra e o decodificador, para manter dados de cada fluxo de energia entre sua chegada, a partir de um canal de dados e seu tempo atual de decodificação e apresentação. T-STD e P-STD são ambos similares na forma geral, conforme explicado mais plenamente na especificação MPEG-2. Entretanto, diferenças entre T-STD e P-STD significam que, em geral, um fluxo de transporte não pode ser mapeado diretamente para um fluxo de programa, sem reprogramar pelo menos no nível dos pacotes PES, e similarmente para conversão do formato PS para TS. Como um exemplo, o decodificador de áudio no formato TS possui um meio de armazenamento temporário menor que no P-STD. Como um outro exemplo, cada armazenamento temporário principal no T-STD é precedido de um meio de armazenamento temporário de transporte que atua para suavizar os dados realmente "em forma de salvas" no próprio fluxo de transporte. Enquanto os dados para um dado fluxo podem chegar em uma salva de diversos pacotes de transporte a uma taxa de pico de 40 mega bits por segundo, a taxa média de tal fluxo, ao levar em conta o multiplex de fluxo de transporte inteiro, é de longe mais baixo. Uma "taxa de perda" é definida para o meio de armazenamento temporário de transporte, de modo a reduzir os dados de entrada para uma taxa de 2 mega bits por segundo, supondo que existem dados a serem passados no meio de armazenamento temporário principal.
Conversão de Fluxo de Programa para Fluxo de Transporte Figura 4 ilustra a abordagem básica para transmultiplexação a partir do Fluxo de Programa de reprodução de sistema de vídeo ótico bem conhecido para um padrão DVB de Fluxo de Transporte requerido pelo decodificador de TV digital 102 no exemplo de aplicação da figura 1. Fluxos de programa de sistema de vídeo de disco ótico bem conhecido são divididos em pacotes PES que se ajustam em 2048 setores de bytes (“packs” PS). Cada setor começa com um cabeçalho “Pack”, transportando o SCR do “pack”. Cada Pack transporta um pacote PES de um tipo de dados único e opcionalmente um pacote de preenchimento. (Um fluxo de sistema de vídeo ótico bem conhecido transportando áudio MPEG-2 é uma exceção - pacotes de base e de extensão podem ser intercalados dentro de um “pack” ). A análise do sistema de disco ótico bem conhecido é muito simples. A estrutura de pacote de sistema de vídeo disco óptico bem conhecido pode ser mantida através do processo de transmultiplexação, porque as restrições do sistema de vídeo de disco ótico bem conhecido na estrutura do pacote PES são mais severas do que as restrições impostas pelo DVB no Fluxo de Transporte a ser gerado (similarmente ATSC, etc.). Por outro lado, será entendido que as técnicas descritas aqui podem ser aplicadas, com adaptação apropriada, a fluxos compatíveis MPEG-2 em geral, e a fluxos elementares empacotados de dados transportados em outros formatos, possuindo propriedades similares.
Em uma visão geral, a entrada do fluxo de sistema de vídeo de disco ótico bem conhecido PS (a partir do disco 106 no exemplo da figura 1) é analisado em 402 e dividido em fluxos paralelos de pacotes PES de cada tipo de dados stream_identifier SID (fluxo de vídeo 404, fluxo de áudio 406). Fluxos gráficos incluídos no multiplex do sistema de vídeo de disco ótico bem conhecido não são especificamente considerados aqui, pois estes são para serem transcodi ficados em vídeo MPEG ou “encontrar” os dados de imagem do mesmo fluxo de vídeo principal, no sentido de aparecer na imagem decodificada. Em princípio, entretanto, fluxos adicionais de gráficos e/ou outros tipos de informação podem também estar presentes, e tratados de maneira similar ao fluxos de áudio e vídeo ilustrados. Os fluxos paralelos A/V PES então cada um em uma fila (meio de armazenamento temporário) 408, 410, respectivamente. Sob controle de um programador 412, os fluxos de dados enfileirados são então divididos, em 414, em pacotes de Transporte de 188 bytes (T-PKT) e intercalados para formar o fluxo de transporte TS, que são então programados e enviados à interface de saída do reprodutor.
Enquanto os componentes funcionais chave e processos da transmultiplexação são mostrados e descritos em blocos separados, será verificado que vários meios de armazenamento temporário e processos descritos aqui podem ser implementados em um processador de finalidade geral e memória compartilhada, usados também para outras finalidades do reprodutor 104 ou outro aparelho. Igualmente, processadores de sinal digital especializados e/ou hardware dedicado, podem ser usados em pontos apropriados, de acordo com considerações de projeto normais. O programador 412 poderá agora ser descrito em mais detalhe. Uma idéia inicial seria manter a mesma programação de dados que é usada no Fluxo de Programa, que é suposto ser de acordo com as exigências PS. Neste caso, os dados elementares deveríam ser transportados no Fluxo de Transporte, tanto quanto possível ao mesmo tempo em que este é transportado no Fluxo de Transporte. Isto teria a vantagem de economizar a necessidade de remultiplexação plena na qual os modelos MPEG STD (Decodificador Alvo de Sistema) tem que ser mantidos e providos grandes meios de armazenamento temporário. Infelizmente, pelo menos duas restrições em MPEG-2 tomam impossível simplesmente aplicar a mesma programação do PS para o TS, permanecendo de acordo com o formato TS: o O tamanho do meio de armazenamento de áudio TS é de 3584 bytes. No Fluxo de Programa de sistema de vídeo de disco ótico bem conhecido é de 4096 bytes, implicando em que o meio de armazenamento temporário de decodificador de conversor set-top box para os dados de áudio possa apresentar estouro de tempo em tempo, e sejam perdidas amostras de áudio. o O modelo de áudio TS STD possui uma taxa máxima instantânea de 2 mega bits por segundo definida pela "taxa de perda" no meio de armazenamento temporário de transporte. Isto pode somente ser excedido para 512 bytes. O sistema de vídeo de disco ótico bem conhecido permite uma taxa de bit de áudio máxima de 10,08 mega bits por segundo (definida por “program_mux_rate) a ser mantida por uma duração de 4096 bytes (dois pacotes). Consequentemente, o multiplex de sistema de vídeo de disco ótico bem conhecido pode fornecer uma salva mais longa de dados, a uma taxa mais alta que o Fluxo de Transporte MPEG-2 (TS) pode conduzir.
Estas duas limitações sugerem que é essencial separar e remultiplexar os fluxos elementares, e reprogramar os dados de acordo com as diferentes restrições impostas no fluxo de saída. Referindo-se novamente à figura 4, conseqüentemente, o programador 412 mantém modelos 416 e 418 de decodificador alvo de sistema (T-STD) especificado para cada fluxo elementar no formato TS. Será entendido que estes modelos não armazenam ou decodificam realmente os dados de fluxo. Entretanto, estabelecendo vários contadores e listas, e atualizando estes ao longo do tempo de acordo com o comportamento especificado no padrão do Sistema MPEG-2, o modelo rasteia o movimento hipotético dos dados, em particular para assegurar que os meios de armazenamento temporário do fluxo em um decodificador real não sofrem estouro ou estouro negativo, de tal modo que os dados não são perdidos, e sempre estarão disponíveis no tempo e na seqüência correta para decodificação e apresentação ao usuário. Com essa finalidade, um Relógio de Sistema TS é a base de tempo chave para a função de remultiplexação, sincronizada com a geração constante do fluxo de transporte. O fluxo de programa de entrada transporta sua própria Referência de Relógio de Sistema (SCR), ambas expressas em termos de um relógio de 27 MHz. Os pacotes TS são gerados a cada período de pacote TS. Eles podem, em princípio, ser gerados exatamente quando requerido, ou podem alimentar um meio de armazenamento temporário curto FIFO para aliviar as restrições de temporização na programação real e geração dos pacotes. O valor corrente do Relógio de Sistema para as finalidades da descrição seguinte é o tempo do pacote TS sendo correntemente gerado, independente de qualquer retardo de armazenamento temporário subseqüente.
Para manter os modelos STD 416, 418 para os fluxos elementares, o programador também conhece o tamanho de cada unidade de acesso, e certos parâmetros para o vídeo (taxa de quadro, marcação de campo de primeira repetição, tipo de imagem, etc.) no sentido de calcular o PTS/DTS para unidades de acesso que não o possuam codificado explicitamente nos cabeçalhos de pacote PES. Notar que o sistema de vídeo de disco ótico bem conhecido, por exemplo, requer somente codificação explícita, nos cabeçalhos PES, de PTS/DTS, na primeira imagem I em cada GOP. É obrigatório, e não comum, que PTS/DTS seja codificado para cada imagem. Similarmente, pode ser vantajoso possuir parâmetros para o fluxo de áudio (taxa de amostragem, tamanho de quadro, etc.).
Portanto, embora o conteúdo dos pacotes PES não seja perturbado (exceto, por exemplo, para remapear o SID/PID para uma estrutura de programa conveniente), é necessário analisar os dados elementares em todos fluxos ativos até o nível de cabeçalho de Cabeçalho de Imagem/Extensão/quadro. Notar que estes estão contidos em localizações de byte arbitrárias nos pacotes PES e portanto os códigos de partida podem ser até divididos entre pacotes PES. O áudio pode ser de taxa de bit variável. Também, ao passo que vários códigos de partida no fluxo de vídeo são únicos no fluxo de bits compatível com MPEG, os códigos de sincronismo de áudio podem, com uma pequena a probabilidade, ser emulados nos dados de carga útil de áudio. Analisar o fluxo de áudio, requer entretanto uma abordagem de máquina de estado para confirmar a sincronização ao longo de diversos quadros, ao invés de uma simples varredura para uma única configuração de bit.
Programador 412: Processo 1 E agora descrito um primeiro exemplo de processo ("Processo 1") para determinar quando enviar pacotes TS, e a partir de que fluxo elementar. Este processo pode se aplicar quando o Fluxo de Programa pode ser lido mais rápido que o tempo real, a partir de um disco, por exemplo. Este pode também se aplicar quando PS precisa ser processado em tempo real, por exemplo, se este é fornecido através de uma interface, mas neste caso o remultiplexador insere um retardo de até 1 segundo. O Processo 1 tem vantagem sobre o Processo 2 (figura 6, ver abaixo) de ser mais simples, um porém usa mais memória para fila intermediária e requer mais retardo do que se o PS fosse fornecido em tempo real.
Figura 5 mostra o processo do programador na forma de fluxograma. Uma malha principal deste fluxograma é executada pelo menos uma vez para cada período de pacote TS, e na prática a malha principal ou subprocessos dentro dele podem ser repetidos várias vezes em cada período TS. O processo de conversão começa na etapa 500 e continua com as seguintes etapas. 502: Ler um setor (pack PS) a partir do fluxo de Programa. Isto é analisado para identificar a extensão de SID e PES. Os dados são descartados se SID indica que não são desejados. Notar que, em geral, MPEG-2 permite diversos pacotes PES e mesmo diversos SID dentro de cada “pack”. O (ou cada) pacote PES é enviado intacto às filas apropriadas (408, 410 na figura 4). O conector B conduz à etapa 502, para uso todas as vezes que um novo setor deve ser lido a partir do PS. 504: Naturalmente, o processo termina quando não há mais “packs” PS a serem lidos (isto pode ser indicado antecipadamente pela estrutura de diretório no disco). 506: A partir dos cabeçalhos e campos do sistema opcional nos fluxos, nos pacotes PES, é determinado se a informação de sistema (SI no sistema de disco de vídeo ótico bem conhecido, PSI em termos MPEG-2) necessita ser inserida no TS para controle adequado do decodifícador. Caso afirmativo, em 508 os dados SI são adicionados a uma fila SI (não mostrada na figura 4). Em 510, é verificado se há espaço para dados SI em um meio de armazenamento temporário SI do decodifícador hipotético, de acordo com o estado atual do STD. Caso afirmativo, em 512, um pacote de Transporte é gerado de acordo. Caso negativo, o processo continua com os dados SI ainda na fila. 520: Entrando agora na malha principal, que é executada continuamente para gerar pacotes de Transporte, uma primeira fila é examinada para determinar se há dados ES aguardando na fila relevante. No presente exemplo, é preferido que o fluxo de áudio seja examinado primeiro, embora todos os fluxos sejam examinados por sua vez. 522: Supondo que existem dados aguardando para serem enviados para o ES primeiro, o modelo de decodifícador alvo do sistema é verificado para ver se o meio de armazenamento temporário para este fluxo pode aceitar um pacote de Transporte adicional. Caso afirmativo, em 524, um pacote de Transporte é adicionado ao fluxo de saída. O conector A leva ao início da malha principal novamente. 526: Se nenhum pacote tivesse gerado a partir da primeira fila (porque a fila estava vazia, ou o meio de armazenamento temporário STD relevante estava cheio), etapas similares às etapas 520-524 são repetidas para cada fluxo elementar, verificando a respectiva fila para dados, verificando a plenitude do meio de armazenamento temporário correspondente no modelo STD, e enviando um pacote de Transporte, se possível. Uma vez que um pacote tenha sido gerado, o controle retoma ao topo da malha principal, via conector A. Etapas para o último fluxo são mostradas em 528-532. 534: Se nenhum dos fluxos tiver sido capaz de programar um pacote de transporte, é feita uma verificação para ver se alguma das filas está vazia. Se existe um fluxo vazio, a conexão B é seguida para buscar um novo setor de dados a partir do fluxo de entrada. 536: Se nenhum das filas está vazia, a conclusão é que todos os meios de armazenamento temporário do STD estão cheios, e uma ação de espera é efetuada escrevendo um pacote de preenchimento (vazio) no fluxo de transporte. Será lembrado que o formato TS compreende pacotes a uma taxa fixa, se os dados estiverem ali para eles ou não, e a ocorrência de pacotes de preenchimento para preencher os dados desejados será algo regular. Pacote de preenchimento são definidos dentro da especificação MPEG-2 para esta finalidade, e são descartados na recepção pelo decodificador. Pela mesma indicação magnética, pacote de preenchimento não têm efeito na plenitude do meio de armazenamento temporário no modelo de decodificador STD. O controle passa então para a etapa 520 e o processo se repete, aguardando e preenchendo se necessário, até que um dos meios de armazenamento temporário tenha espaço para um novo pacote de transporte.
Notar que o primeiro fluxo (áudio na realização) recebe uma espécie de prioridade, no esquema ilustrado pela figura 5. Quer dizer, enquanto a primeira fila possui dados e o primeiro meio de armazenamento temporário tem espaço no STD, os pacotes de transporte a partir daquele fluxo serão enviados de preferência para outros fluxos. Os inventores escolheram implementar tal prioridade no presente exemplo, porque o número de fluxos é limitado e, programar no fluxo de áudio, decididamente tem a menor liberdade. O algoritmo exato não é crítico, entretanto, e outras opções podem ser visualizadas para seguir diferentes circunstâncias. Por exemplo, para maximizar o intercalamento de dados a partir de fluxos diferentes de características similares, é somente necessário mudar a conexão da etapa 524 para conduzir à etapa 526, ao invés de retomar na malha para A, e assim por diante para fluxos subseqüentes, até o último. Deste modo, somente quando todos fluxos tenham sido tentados, e um pacote enviado onde possível, a malha será feita para a etapa 520, e o primeiro fluxo tentado novamente. As mesmas considerações se aplicam em relação ao Processo 2, descrito abaixo.
Análise do Processo 1 O algoritmo de programação acima busca um outro pacote PS, todas as vezes que uma das filas de fluxo elementar está vazia. Isso significa que o programador TS 412 sempre tem uma escolha ilimitada de dados elementares para encontrar um pacote que se ajuste às restrições de multiplex TS. A programação de pacote PS então não tem impacto na programação do multiplex TS.
Uma vez que não há dependência entre a programação de fluxo de entrada e a programação de fluxo de saída, e sabemos que um multiplexador TS sempre pode encontrar uma programação válida, está claro que este algoritmo não tem condições de impasse. O preço desta simplicidade é o armazenamento temporário, entretanto, e em casos em que o PS não pode ser lido mais rápido do que o tempo real, um retardo de transcodifícação de cerca de 1 s. O "pior caso" para ocupação de fila e retardo de armazenamento temporário será quando existe um desvio máximo entre os fluxos elementares.
Considere, por exemplo, um fluxo de áudio e um fluxo de vídeo. Suponha um quadro de áudio particular, N, que é entregue pelo PS muito tarde (exatamente antes de seu tempo de decodificação DTS), e o quadro de áudio prévio do mesmo fluxo (N-l) é entregue muito cedo. O programador TS inserirá o quadro N-l no fluxo de transporte TS algum tempo após este chegar no transmultiplexador. Este então não programará quaisquer pacotes, nem áudio nem vídeo, até que o quadro de áudio N seja lido a partir do PS. Todos os quadros de vídeo nesse meio tempo serão buscados, entretanto, tem que ser enfíleirados no transmultiplexador. O pior caso de extensão de fila e retardo pode ser derivado para esta situação, usando a " segunda regra" MPEG. Esta regra diz que o retardo de decodificação máximo para qualquer unidade de acesso (por exemplo para o quadro N-l) é ls. Então, ls é o tempo máximo possível entre a entrega do quadro N-l e do quadro N (um limite marginalmente mais apertado pode ser derivado). Portanto, 1 s é um limite superior no retardo, e pode ser usado para calcular extensões de fila. Um meio de armazenamento temporário em tomo de 230 kbytes é então requerido para ls de fluxo de vídeo, mais próximo de 300 kbytes na prática.
Programador 412: Processo 2 Figura 6 mostra um procedimento modificado para programar o fluxo de transporte, com menos exigência de armazenamento temporário. O procedimento nas etapas 600-634 é o mesmo das etapas 500-534 na figura 5 (Processo 1). Entretanto, o processo modificado usa efetivamente o conhecimento de que o fluxo de entrada é um Fluxo de Programa com uma programação de multiplex PS legal para introduzir uma dependência entre as duas programações e daí reduzir o retardo. A nova etapa é em 638, que compara o valor de Referência de Relógio de Sistema (SCR) (incluído no último “pack” PS buscado), com o relógio de sistema TSC. Lembrar que TSC indica progresso na geração do fluxo de transporte, enquanto SCR indica progresso na busca do fluxo de entrada PS. Enquanto, no Processo 1, novos dados são buscados do fluxo de entrada todas as vezes que qualquer das filas é encontrado vazia, a etapa extra em 638/640 permite que novos dados sejam buscados somente se SCR é menor que um limiar predeterminado MIN adiante de TSC. Em outras palavras, mesmo se existe um armazenador temporário de fila vazio, novos dados não serão buscados enquanto o fluxo de entrada tiver sido lido à frente por uma quantidade suficiente. Notar que TSC está avançando o tempo todo, mesmo com a geração de pacotes de preenchimento, ao passo que SCR somente avança como e quando novos dados são buscados do fluxo de entrada PS (disc). Se a diferença de tempo MIN na etapa 638 pode ser ajustada substancialmente menor que aquele ls de retardo máximo permitido por MPEG-2, podemos ver imediatamente que o armazenamento temporário requerido para as filas se tomará proporcionalmente menor. Efetivamente, isto significa que, no exemplo acima, podemos enviar muitos pacotes de vídeo, enquanto estivermos aguardando o próximo quadro de áudio.
No exemplo de converter um fluxo de programa compatível MPEG-2 de sistema de vídeo de disco óptico bem conhecido para um fluxo de transporte, há duas razões para reprogramar os pacotes, conforme já mencionado. Uma é a limitação de 2 Mbits/s na taxa de perda do meio de armazenamento temporário de transporte de áudio em um Fluxo de Transporte. A outra é a diferença nos tamanhos do meio de armazenamento temporário de áudio principal entre Fluxos de Transporte e Fluxos de Programas (3584 versus 4096 bytes). Se examinarmos estes dois casos, podemos ver quanta liberdade o programador de pacote TS necessita para encontrar uma programação compatível, dado que a entrada é um fluxo de programa compatível.
Suponha que o áudio é de 48 kHz MPEG com uma duração de quadro de 24 ms. O leitor especialista, verá facilmente como generalizar o argumento para outras suposições tais como taxa de amostragem diferente, ou codificação AC3, enquanto o tamanho do quadro é conhecido. O sistema de vídeo de disco óptico bem conhecido permite que as taxas de bit de áudio MPEG permaneçam entre 32 kbits/s e 448 kbits/s. Em 32 kbits/s o tamanho da unidade de acesso (tamanho de um quadro comprimido) é 0,024 x 32000/8 = 96 bytes. Em 448 kbits/s o tamanho da unidade de acesso (tamanho de um quadro comprimido) é 0,024 x 448000/8 = 1344 bytes. O sistema de vídeo de disco óptico bem conhecido program_mux_rate (a taxa na qual um quadro único é fornecido no fluxo de entrada) é 10,08 Mbits/s. A taxa de perda de meio de armazenamento temporário TS áudio TB é de 2 Mbits/s (Rleak). No pior caso, isto representa a taxa máxima na qual um quadro de áudio pode ser transportado pelo multiplex TS. Considere cada um dos dois casos separadamente: Limitação TB de 2 Mbits/s Considere o quadro de áudio N de tamanho máximo Bn (1344 bytes) fornecido pelo PS no instante mais tarde possível — exatamente antes de seu tempo de decodificação - DTSn. O primeiro byte do quadro N será fornecido no PS em: Tps <= DTSn - Bn / (Rmux) No pior caso este pode levar pelo menos delta Tts = (Bn / Rleak) para enviar este quadro no Fluxo de Transporte. Assim, o primeiro byte no quadro pode ser enviado em: Tts = DTSn - delta Tts. O fluxo de Programa precisa ser armazenado temporariamente no transmultiplexador por pelo menos (Tts - Tps) segundos, para dar ao programador a liberdade que este necessita para resolver este problema. Considerando os valores do sistema de vídeo de disco óptico bem conhecido mencionado acima, Bn / Rlek = 1344/(2x106/8) = 5,376 ms Bn / Rmux = 1344/(10,08x106/8) = 1,067 ms Portanto, o retardo de transmultiplex mínimo requerido para dar liberdade de programação a partir desta restrição é 4,31 ms.
Diferença de tamanho de meio de armazenamento temporário Considere um fluxo de programa que possui uma programação de pacote que preenche exatamente o meio de armazenamento temporário de áudio PS em algum instante. Como o meio de armazenamento temporário de áudio TS é menor, não é possível transmitir alguns destes quadros de áudio imediatamente. Eles precisam ser retardados até que o meio de armazenamento temporário de áudio TS tenha esvaziado o bastante para permitir que eles sejam programados. Para manter sincronismo A/V e evitar estouro negativo em outros fluxos, todos os fluxos precisam ser retardados do mesmo tempo. A diferença no tamanho do meio de armazenamento temporário é de 4096 - 3584 bytes = 512 bytes. Isto representa o pior caso (tempo mais longo) quando a taxa de dados é mais baixa. Quando a taxa de dados é 32 kbits/s, o tamanho de quadro é de 96 bytes. 512/96 = 5,33 quadros, que pode ser arredondado para 6 quadros pois o quadro inteiro precisa estar presente no meio de armazenamento temporário no tempo de decodificação do quadro, de acordo com o modelo MPEG. Seis quadros representam 144 ms.
Então, para dar ao programador TS liberdade para superar esta restrição, necessitamos impor um retardo de 6 quadros de áudio (144 ms), que também excede a restrição de 4,31 ms sugerida pela limitação de taxa de perda. Grosseiramente falando, então, o Processo 2 permite a reprogramação dos pacotes PES, do formato PS para TS, com cerca de 1/6 do retardo que seria esperado a partir de uma consideração das restrições do formato TS sozinho. O retardo de 144 ms pode ser reduzido de algo se o fluxo de entrada pode ser lido no transmultiplexador em menos que o tempo real.
Notar neste caso que a prioridade ao fluxo de áudio (primeiro fluxo no fluxograma, mas correspondendo ao “segundo fluxo” na introdução e reivindicações) é importante para assegurar que o retardo de 144 ms será usado quando necessário para satisfazer as restrições identificadas. Por outro lado, diafragmas algoritmos podem ser usados para prover a prioridade necessária, enquanto permitem que outros fluxos tomem prioridade quando seu próprio progresso se toma mais crítico. Um esquema que designa prioridade ao fluxo cujo meio de armazenamento temporário STD possui a percentagem de preenchimento mais baixa, pode ser igualmente válido. Um esquema de prioridade rígido mais livre pode ser aplicado juntamente com escalamento para cima do limiar de espera, para prover liberdade adicional medida.

Claims (9)

1. PROCESSO PARA CONVERTER UM FLUXO DE DADOS DE ENTRADA, possuindo um formato de Fluxo de Programa (PS) em um fluxo de dados de saída possuindo um formato de Fluxo de Transporte (TS), o processo compreendendo: (a) ler, a partir do citado fluxo de dados de entrada, blocos sucessivos de dados, citado fluxo de dados de entrada incluindo dados de pelo menos primeiro e segundo fluxos de dados elementares, formados e multiplexados em conformidade com um modelo de decodificador PS; (b) acumular os dados do primeiro e segundo fluxos elementares, respectivamente na primeira e segunda estruturas de fila; (c) estabelecer um modelo de decodífícador alvo TS, incluindo primeiro e segundo meios de armazenamento temporário hipotéticos para o primeiro e segundo fluxos elementares, respectivamente; (d) gerar uma sucessão de pacotes de transporte para formar citado fluxo de dados de saída conduzindo citados primeiro e segundo fluxos de dados no citado formato TS, por referência ao citado modelo de decodífícador alvo; e (e) atualizar o estado dos citados primeiro e segundo meios de armazenamento temporário hipotéticos dentro do citado decodífícador alvo TS em resposta a cada pacote de transporte gerado e propriedades predeterminadas do citado modelo do decodífícador; em que cada pacote de transporte compreende dados a partir da primeira fila, segunda fila ou nenhuma das duas filas, dependendo da programação dos citados fluxos elementares dentro do fluxo de dados de entrada e no estado dos citados primeiro e segundo meios de armazenamento temporário dentro do citado modelo de decodífícador alvo TS, e onde o processo inclui inibir a leitura de um bloco de dados adicional a partir do citado fluxo de entrada quando, uma referência de relógio do citado fluxo de dados de entrada avança além de uma referência de relógio do citado fluxo de dados de saída, de um limiar de espera predeterminado, caracterizado por cada um dos formatos PS e TS definir restrições como: (i) limite superior na diferença de tempo máxima (desvio) entre tempos de entrega para respectivas unidades de apresentação, no primeiro e segundo fluxos elementares, possuindo um tempo de apresentação comum; e pelo menos um dentre (ii) capacidade de armazenamento temporário de dados para cada fluxo elementar entre entrega e decodificação; e (iii) taxa de entrega de dados de cada fluxo elementar na escala de uma unidade de acesso, a partir do fluxo de transporte para um meio de armazenamento temporário para decodificação, e em que a citada restrição de meio de armazenamento temporário (ii) é mais estrita no formato TS do que no formato PS, para o segundo fluxo elementar, e onde citado limiar de espera é suficiente para acomodar uma quantidade de excesso de dados correspondente à diferença, entre os quais podem ser acomodados dentro do meio de armazenamento temporário no decodificador alvo PS que podem ser acomodados no decodificador alvo TS, e em que citado limiar de espera é menor que 1/5 do desvio permitido no fluxo de programa.
2. PROCESSO, de acordo com qualquer uma das reivindicações anteriores, caracterizado pela citada unidade de acesso compreender um quadro de áudio comprimido.
3. PROCESSO de acordo com qualquer uma das reivindicações anteriores, caracterizado pela taxa de dados média do primeiro fluxo elementar ser pelo menos 3 ou 4 vezes maior que aquela do segundo fluxo elementar.
4. PROCESSO, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelos dados do primeiro fluxo elementar compreenderem imagens de vídeo codificadas e os dados do segundo fluxo elementar compreenderem quadros de áudio codificados.
5. PROCESSO, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo citado formato TS ser conforme à especificação de Fluxo de Transporte MPEG-2, enquanto citado formato PS é conforme à especificação de Fluxo de Programa MPEG-2, ambas conforme definido na ITU-T Recomendação H.222.0 e ISO/IEC 13818-1.
6. PROCESSO PARA REPRODUZIR UM PROGRAMA ÁUDIO VISUAL GRAVADO, caracterizado por um fluxo de dados no formato PS ser lido a partir de um canal de dados, convertido para um formato TS por um processo conforme definido em qualquer uma das reivindicações anteriores, e alimentado através de um canal adicional a um decodificador compatível TS.
7. PROCESSO, de acordo com a reivindicação 6, caracterizado pelo citado canal de dados compreender uma gravação do citado fluxo de dados de entrada em uma portadora de gravação.
8. APARELHO, compreendendo meios para receber um fluxo de dados de entrada em um primeiro formato, em que pelo menos dois fluxos elementares de dados serem multiplexados, e meio para converter os dados para um segundo formato, para gerar um fluxo de saída, caracterizado pelo citado meio de conversão compreendendo meio adaptado especificamente para implementar um processo, conforme definido em qualquer uma das reivindicações anteriores.
9. APARELHO, de acordo com a reivindicação 8, caracterizado pelo aparelho compreender um dentre um aparelho decodificador independente para programas de vídeo digital, um aparelho de apresentação possuindo um mostrador para programas de vídeo, e um aparelho de reprodução para reproduzir e opcionalmente também para gravar programas de vídeo digital.
BRPI0008604-5A 1999-12-30 2000-12-04 Processos para converter um fluxo de dados de entrada, e para reproduzir um programa audiovisual gravado, e, aparelho BRPI0008604B1 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB9930787.8A GB9930787D0 (en) 1999-12-30 1999-12-30 Method and apparatus for convrerting data streams
PCT/EP2000/012240 WO2001050761A1 (en) 1999-12-30 2000-12-04 Method and apparatus for converting data streams

Publications (2)

Publication Number Publication Date
BR0008604A BR0008604A (pt) 2002-01-22
BRPI0008604B1 true BRPI0008604B1 (pt) 2015-07-14

Family

ID=10867140

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0008604-5A BRPI0008604B1 (pt) 1999-12-30 2000-12-04 Processos para converter um fluxo de dados de entrada, e para reproduzir um programa audiovisual gravado, e, aparelho

Country Status (10)

Country Link
US (1) US6901078B2 (pt)
EP (1) EP1208698B1 (pt)
JP (1) JP4828760B2 (pt)
KR (1) KR100822778B1 (pt)
CN (1) CN1274154C (pt)
BR (1) BRPI0008604B1 (pt)
GB (1) GB9930787D0 (pt)
MY (1) MY129235A (pt)
TW (1) TW580810B (pt)
WO (1) WO2001050761A1 (pt)

Families Citing this family (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7088725B1 (en) * 1999-06-30 2006-08-08 Sony Corporation Method and apparatus for transcoding, and medium
US7020384B1 (en) * 1999-08-12 2006-03-28 Lg Electronics Inc. Method for creating and recording transport time information for data recorded on a disk
KR100376578B1 (ko) 1999-08-12 2003-03-17 엘지전자 주식회사 디지털 데이터 스트림 기록방법 및 그에 따른 표현제어정보 제공방법
US20010015917A1 (en) * 1999-12-31 2001-08-23 Heo Jung-Kwon Recording medium having data recorded in data structure capable of editing additional data related to audio data, method and apparatus of recording and/or reproducing thereof
KR100394974B1 (ko) * 2000-05-23 2003-08-19 엘지전자 주식회사 고밀도 광 기록매체에서의 멀티경로 데이터를 수용하는 방법
US7366402B2 (en) * 2000-06-02 2008-04-29 Lg Electronics Inc. Method and apparatus of recording a high definition digital television broadcast signal
JP4552290B2 (ja) * 2000-08-21 2010-09-29 ソニー株式会社 データ伝送装置及び方法、データ処理装置及び方法
US6996101B2 (en) * 2000-11-29 2006-02-07 International Business Machines Corporation Re-mapping and interleaving transport packets of multiple transport streams for processing by a single transport demultiplexor
KR100470025B1 (ko) * 2001-06-15 2005-02-04 엘지전자 주식회사 디지털 데이터 스트림 기록장치 및 방법과, 그에 따른기록매체
KR100752480B1 (ko) * 2001-06-21 2007-08-28 엘지전자 주식회사 멀티채널 스트림 기록장치 및 방법과, 그에 따른 기록매체
KR100598285B1 (ko) * 2001-06-21 2006-07-07 엘지전자 주식회사 멀티채널 스트림 기록장치 및 방법과, 그에 따른 기록매체
KR20020097454A (ko) 2001-06-21 2002-12-31 엘지전자 주식회사 멀티채널 스트림 기록장치 및 방법과, 그에 따른 기록매체
GB0116119D0 (en) * 2001-06-30 2001-08-22 Koninkl Philips Electronics Nv Transcoding of video data streams
KR100752482B1 (ko) * 2001-07-07 2007-08-28 엘지전자 주식회사 멀티채널 스트림 기록 재생장치 및 방법
US7643727B2 (en) * 2001-07-24 2010-01-05 Lg Electronics Inc. Method and apparatus of recording a multi-channel stream, and a recording medium containing a multi-channel stream recorded by said method
EP1391119B1 (en) * 2001-11-30 2006-06-14 Matsushita Electric Industrial Co., Ltd. A method and an apparatus for data recording
ATE292873T1 (de) * 2001-11-30 2005-04-15 Matsushita Electric Ind Co Ltd Verfahren und vorrichtung zur stream-umsetzung, verfahren und vorrichtung zur datenaufzeichnung und datenaufzeichnungsmedium
US7209874B2 (en) * 2002-02-25 2007-04-24 Zoran Corporation Emulator-enabled network connectivity to a device
US7269543B2 (en) * 2002-02-25 2007-09-11 Zoran Corporation System and method for providing network connectivity to a common embedded interface by stimulating the embedded interface
US9122808B2 (en) * 2002-02-25 2015-09-01 Csr Technology Inc. Network interface to a video device
KR100396579B1 (ko) * 2002-04-29 2003-09-02 삼성전자주식회사 광학 기록/재생 장치
US7889968B2 (en) * 2002-06-24 2011-02-15 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple reproduction path video data for at least a segment of a title recorded thereon and recording and reproducing methods and apparatuses
KR20040000290A (ko) 2002-06-24 2004-01-03 엘지전자 주식회사 고밀도 광디스크의 멀티 경로 데이터 스트림 관리방법
CN101350214B (zh) 2002-06-24 2015-07-01 Lg电子株式会社 记录和再现用于视频数据的再现的数据结构的方法及装置
JP4390701B2 (ja) * 2002-06-24 2009-12-24 エルジー エレクトロニクス インコーポレイティド 多重再生経路ビデオデータの再生を管理するためのデータ構造を有する記録媒体とそれによる記録及び再生方法及び装置
US7933411B2 (en) * 2002-06-28 2011-04-26 Trident Microsystems (Far East) Ltd. Method of constructing MPEG program streams from encrypted MPEG transport streams
AU2003243049B2 (en) * 2002-06-28 2010-03-04 Lg Electronics Inc. Recording medium having data structure for managing recording and reproduction of multiple path data recorded thereon and recording and reproducing methods and apparatus
EP1518239A4 (en) * 2002-06-28 2010-03-10 Lg Electronics Inc RECORDING MEDIUM WITH A DATA STRUCTURE FOR MANAGING THE REPRODUCTION OF MULTIPLE PLAY VIDEO DATA RECORDED THEREFOR AND RECORDING AND PLAYING METHOD AND DEVICES
US7519728B1 (en) * 2002-07-18 2009-04-14 Juniper Networks, Inc. Merge systems and methods for transmit systems interfaces
KR20040009927A (ko) * 2002-07-26 2004-01-31 삼성전자주식회사 Dtv 스트림 생성을 위한 정보를 저장하는정보저장매체, dtv 스트림 변환 방법 및 그 장치
CN1685420B (zh) * 2002-11-08 2010-07-07 Lg电子有限公司 在高密度记录介质上记录多成分数据流及其重现的方法和装置
AU2003276756B2 (en) * 2002-11-12 2007-09-13 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7720356B2 (en) 2002-11-12 2010-05-18 Lg Electronics Inc Recording medium having data structure for managing reproduction of multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7783160B2 (en) * 2002-11-20 2010-08-24 Lg Electronics Inc. Recording medium having data structure for managing reproduction of interleaved multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7664372B2 (en) * 2002-11-20 2010-02-16 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple component data recorded thereon and recording and reproducing methods and apparatuses
US7606463B2 (en) * 2003-02-24 2009-10-20 Lg Electronics, Inc. Recording medium having data structure for managing playback control and recording and reproducing methods and apparatuses
US7809775B2 (en) 2003-02-27 2010-10-05 Lg Electronics, Inc. Recording medium having data structure for managing playback control recorded thereon and recording and reproducing methods and apparatuses
EP1604356A4 (en) * 2003-02-28 2009-12-16 Lg Electronics Inc RECORD MEDIUM WITH A DATA STRUCTURE FOR MANAGING THE RANDOM / SHUFFLE PLAYBACK OF RECORDED VIDEO DATA, AND METHOD AND DEVICES FOR RECORDING AND PLAYING
CN100583239C (zh) * 2003-02-28 2010-01-20 松下电器产业株式会社 再生装置及再生方法
WO2004082181A1 (ja) * 2003-03-10 2004-09-23 Matsushita Electric Industrial Co., Ltd. Ofdm信号の送信方法、送信装置及び受信装置
ES2434104T3 (es) 2003-03-17 2013-12-13 Koninklijke Philips N.V. Aparato para y método para almacenar un flujo en tiempo real de señales de información digitales
US7224664B2 (en) * 2003-03-25 2007-05-29 Lg Electronics Inc. Recording medium having data structure for managing reproduction of data streams recorded thereon and recording and reproducing methods and apparatuses
JP3817257B2 (ja) * 2003-04-10 2006-09-06 松下電器産業株式会社 情報記録媒体、情報記録媒体に情報を記録する装置及び方法
KR100956821B1 (ko) * 2003-05-24 2010-05-11 엘지전자 주식회사 Pvr 재생 방법
JP4346966B2 (ja) 2003-06-13 2009-10-21 キヤノン株式会社 撮像装置
KR20060027346A (ko) * 2003-06-17 2006-03-27 코닌클리케 필립스 일렉트로닉스 엔.브이. 스터핑 바이트 제거를 갖는 dvd-멀티미디어 홈 플래폼용스트림 파일 포맷
EP2383743B1 (en) * 2003-06-18 2012-10-24 Panasonic Corporation Playback apparatus, recording medium, program, and playback method
US7882510B2 (en) * 2003-08-06 2011-02-01 Microsoft Corporation Demultiplexer application programming interface
EP1562382B1 (en) * 2004-01-26 2019-09-04 Socionext Inc. Format conversion device and format conversion method
JP2005322977A (ja) * 2004-05-06 2005-11-17 Canon Inc カメラ一体型記録再生装置
US7706415B2 (en) * 2004-07-29 2010-04-27 Microsoft Corporation Packet multiplexing multi-channel audio
KR100725387B1 (ko) 2004-08-24 2007-06-08 삼성전자주식회사 데이터 방송에서의 전송 코드 세트 시그널링 방법 및 장치
US20080035176A1 (en) * 2004-08-25 2008-02-14 Byers Ernest F Automated Cart and Container Cleaning System
CN100336402C (zh) * 2005-03-16 2007-09-05 西安电子科技大学 Mpeg-2单节目传输流多路复用方法
CN101151829A (zh) * 2005-04-07 2008-03-26 诺基亚公司 流传送中的缓存
CA2615925A1 (en) * 2005-07-19 2007-01-25 March Networks Corporation Hierarchical data storage
KR100740210B1 (ko) * 2005-10-21 2007-07-18 삼성전자주식회사 듀얼 전송 스트림 생성 장치 및 그 방법
KR100788685B1 (ko) * 2006-03-10 2007-12-26 삼성전자주식회사 데이터 스트림 포맷의 변환 방법 및 장치, 이를 이용한데이터 스트림 기록 방법 및 장치
US20080159713A1 (en) * 2006-12-28 2008-07-03 Mediatek Inc. Digital Video Recorder, Multimedia Storage Apparatus, And Method Thereof
US8045582B1 (en) * 2009-05-27 2011-10-25 Lockheed Martin Corporation Variable bandwidth communication system
CN101605252B (zh) * 2009-07-17 2011-07-20 深圳创维数字技术股份有限公司 将节目流转换成传输流的方法和系统
KR101694821B1 (ko) * 2010-01-28 2017-01-11 삼성전자주식회사 다시점 비디오스트림에 대한 링크 정보를 이용하는 디지털 데이터스트림 전송 방법와 그 장치, 및 링크 정보를 이용하는 디지털 데이터스트림 전송 방법과 그 장치
DE102010029030A1 (de) * 2010-05-17 2012-03-01 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Verarbeitung von Daten in einem Fahrzeug
CN102104795A (zh) * 2011-03-30 2011-06-22 重庆大学 基于mpeg-2的多路ps流转复用为一路ts流的方法
US20120281704A1 (en) * 2011-05-02 2012-11-08 Butterworth Ashley I Methods and apparatus for isochronous data delivery within a network
KR20120138319A (ko) * 2011-06-14 2012-12-26 삼성전자주식회사 멀티미디어 데이터 특징 정보를 이용하여 멀티미디어 서비스 데이터 패킷을 송신하는 방법 및 장치
JPWO2013118545A1 (ja) * 2012-02-07 2015-05-11 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、プログラムおよび電子機器
CN103179436B (zh) * 2013-03-14 2016-08-03 北京大学 一种多路节目传输流复用装置
CN103596043B (zh) * 2013-11-14 2017-05-10 上海电力学院 一种数字电视中ts流转化为ps流的方法
US20180263916A1 (en) 2015-09-28 2018-09-20 Puracap Pharmaceutical Llc Soft gelatin capsules containing a mixture of analgesics and decongestants, expectorants, antitussives and/or antihistamines
CN108141636B (zh) * 2015-10-07 2021-03-23 松下知识产权经营株式会社 接收装置以及接收方法
US10218755B2 (en) 2016-01-29 2019-02-26 Roku, Inc. Extended selection and alignment of video segments for adaptive streaming
US10057654B2 (en) 2016-01-29 2018-08-21 Roku, Inc. Selection and alignment of video segments for adaptive streaming
US10122781B2 (en) * 2016-01-29 2018-11-06 Roku Inc. Selection of video segments for adaptive streaming
CN105959656B (zh) * 2016-07-15 2018-12-11 常州市小先信息技术有限公司 一种数字标牌的视频监控和录像回放安全机制方法
KR20180060804A (ko) * 2016-11-29 2018-06-07 삼성전자주식회사 전자장치, 전자장치의 제어방법 및 기록매체
US10645199B2 (en) * 2018-01-22 2020-05-05 Lattice Semiconductor Corporation Multimedia communication bridge
US20200106699A1 (en) * 2018-10-01 2020-04-02 Citrix Systems, Inc. Systems and methods for multilink wan connectivity for saas applications

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566174A (en) * 1994-04-08 1996-10-15 Philips Electronics North America Corporation MPEG information signal conversion system
US6172988B1 (en) * 1996-01-31 2001-01-09 Tiernan Communications, Inc. Method for universal messaging and multiplexing of video, audio, and data streams
US6052556A (en) * 1996-09-27 2000-04-18 Sharp Laboratories Of America Interactivity enhancement apparatus for consumer electronics products
JPH10154373A (ja) 1996-09-27 1998-06-09 Sony Corp データデコードシステムおよびデータデコード方法、伝送装置および方法、並びに、受信装置および方法
JP2885217B2 (ja) 1997-02-21 1999-04-19 日本電気株式会社 Mpegデータ処理回路
JPH1145512A (ja) * 1997-07-25 1999-02-16 Hitachi Ltd ディジタルディスクレコーダ
JP4004147B2 (ja) * 1997-07-29 2007-11-07 松下電器産業株式会社 データ送信装置,データ受信装置およびデータ記録装置
US6618396B1 (en) * 1997-07-29 2003-09-09 Matsushita Electric Ind Co Ltd Data transmitting device, data receiving device, and data recording device
JP3844877B2 (ja) * 1998-04-08 2006-11-15 パイオニア株式会社 ストリーム変換装置
US6327275B1 (en) * 1998-05-19 2001-12-04 General Instrument Corporation Remultiplexing variable rate bitstreams using a delay buffer and rate estimation

Also Published As

Publication number Publication date
BR0008604A (pt) 2002-01-22
KR100822778B1 (ko) 2008-04-17
CN1274154C (zh) 2006-09-06
JP2003519985A (ja) 2003-06-24
CN1349715A (zh) 2002-05-15
EP1208698A1 (en) 2002-05-29
JP4828760B2 (ja) 2011-11-30
GB9930787D0 (en) 2000-02-16
US6901078B2 (en) 2005-05-31
MY129235A (en) 2007-03-30
KR20010102435A (ko) 2001-11-15
US20010007568A1 (en) 2001-07-12
WO2001050761A1 (en) 2001-07-12
TW580810B (en) 2004-03-21
EP1208698B1 (en) 2011-10-05

Similar Documents

Publication Publication Date Title
BRPI0008604B1 (pt) Processos para converter um fluxo de dados de entrada, e para reproduzir um programa audiovisual gravado, e, aparelho
JP4731083B2 (ja) データストリームの変換方法と装置
US5619337A (en) MPEG transport encoding/decoding system for recording transport streams
JP4294676B2 (ja) Mpeg情報信号変換システム
US7313315B2 (en) Methods and apparatus for making and replaying digital video recordings, and recordings made by such methods
US6952521B2 (en) Methods and apparatus for editing digital video recordings, and recordings made by such methods
JP4490811B2 (ja) 暗号化mpegトランスポートストリームからmpegプログラムストリームを作成する方法
KR100534291B1 (ko) 디지털 방송 기록 재생 장치
JP3804099B2 (ja) 映像素材供給装置及び方法、映像素材挿入装置及び方法
WO2000027113A1 (fr) Appareil et procede d&#39;enregistrement et de reproduction
JP4147452B2 (ja) 多重化装置および方法、記録媒体、並びにプログラム

Legal Events

Date Code Title Description
B06A Notification to applicant to reply to the report for non-patentability or inadequacy of the application [chapter 6.1 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B25D Requested change of name of applicant approved
B25G Requested change of headquarter approved
B16A Patent or certificate of addition of invention granted

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 14/07/2015, OBSERVADAS AS CONDICOES LEGAIS.

B25G Requested change of headquarter approved
B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 18A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2494 DE 23-10-2018 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.