BRPI0517365B1 - inserção de metadados para controle de reprodução em fluxo de transporte de vídeo - Google Patents

inserção de metadados para controle de reprodução em fluxo de transporte de vídeo Download PDF

Info

Publication number
BRPI0517365B1
BRPI0517365B1 BRPI0517365A BRPI0517365A BRPI0517365B1 BR PI0517365 B1 BRPI0517365 B1 BR PI0517365B1 BR PI0517365 A BRPI0517365 A BR PI0517365A BR PI0517365 A BRPI0517365 A BR PI0517365A BR PI0517365 B1 BRPI0517365 B1 BR PI0517365B1
Authority
BR
Brazil
Prior art keywords
transport
metadata
video
data
information
Prior art date
Application number
BRPI0517365A
Other languages
English (en)
Inventor
Scott Deiss Michael
Original Assignee
Interdigital Madison Patent Holdings
Thomson Licensing
Thomson Licensing Dtv
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 Interdigital Madison Patent Holdings, Thomson Licensing, Thomson Licensing Dtv filed Critical Interdigital Madison Patent Holdings
Publication of BRPI0517365A publication Critical patent/BRPI0517365A/pt
Publication of BRPI0517365B1 publication Critical patent/BRPI0517365B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/782—Television signal recording using magnetic recording on tape
    • H04N5/783—Adaptations for reproducing at a rate different from the recording rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/781—Television signal recording using magnetic recording on disks or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/907—Television signal recording using static stores, e.g. storage tubes or semiconductor memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation 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/8042—Transformation 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

inserção de metadados para controle de reprodução em fluxo de transporte de vídeo. trata-se de um sistema receptor de video (20) que é condicionado para extrair metadados de controle de reprodução, correspondendo à informação de vídeo, de um fluxo de transporte recebido. o sistema receptor de video (20) identifica a presença de tais metadados em resposta à informação presente no cabeçalho de um pacote de transporte (160) . o receptor de video, após extrair os metadados, armazena os dados correspondendo a tais metadados em uma tabela (175). ao implementar uma função de controle de reprodução durante a reprodução do video, o sistema receptor de vídeo (20) utiliza os dados na tabela para implementar uma função de controle de reprodução desejada. a inserção dos metadados no fluxo de transporte é feita usando o bit de prioridade de transporte, a carga útil ou os pacotes de transporte.

Description

“INSERÇÃO DE METADADOS PARA CONTROLE DE REPRODUÇÃO
EM FLUXO DE TRANSPORTE DE VÍDEO”
REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS
Este pedido reivindica o benefício do Pedido US Provisório de N- 60/612.624, depositado em 23 de Setembro de 2004.
CAMPO DA INVENÇÃO
A presente invenção se relaciona de forma geral com sistemas de transmissão digital, mais particularmente com sistemas de transmissão de vídeo que suportam funções de controle de reprodução.
ANTECEDENTES DA INVENÇÃO
Ao transmitir um programa de vídeo via um sistema de distribuição digital, tal como a cabo, por satélite, por ondas de ar, através da Internet, entre outros, o programa de vídeo é distribuído como uma série de pacotes de dados que são conseqüentemente decodificados por um receptor de vídeo. Atualmente, os sistemas de distribuição de vídeo que utilizam transmissões por satélite ou pelo ar são normalmente conhecidos como sendo uma transmissão “unidirecional”, onde a maioria das informações de vídeo é transmitida por um difusor de programa para um receptor de vídeo (na forma de um dispositivo, tal como um decodificador de sinais ou aparelho de televisão). Entretanto, se um dispositivo receptor suportar um canal de retorno, a quantidade de informação que pode ser transmitida de volta para um difusor (ascendente) normalmente é menor do que é transmitido pelo difusor para o dispositivo receptor (descendente).
Petição 870190124947, de 28/11/2019, pág. 8/32
Entretanto, ao distribuir conteúdo de vídeo através de uma transmissão de satélite ou de uma difusão pelo ar, tais sistemas de distribuição não suportam funções de controle de reprodução, como por exemplo avanço rápido, retrocesso, pausa e saltar para frente / para trás uma quantidade de tempo especificada, já que não há uma maneira de um difusor suportar tais recursos durante a transmissão de vídeo para um grande número de receptores de vídeo. De forma específica, se cada usuário operando um receptor de vídeo desejasse uma função de controle de reprodução diferente ao mesmo tempo, não haveria como o difusor suportar de maneira eficaz todas essas funções devido às limitações da largura de banda de difusão disponível ao difusor.
SUMÁRIO DA INVENÇÃO
De acordo com um aspecto da presente invenção, é proporcionado um aparelho e método para difundir pacotes de dados que contêm informações relacionadas ao suporte de uma função de controle de reprodução em um receptor de vídeo.
Ainda de acordo com outra modalidade da presente invenção, é proporcionado um aparelho e método para suportar uma função de controle de vídeo em um receptor de vídeo, utilizando as informações que são transmitidas como parte de uma transmissão de um difusor.
Esses e outros aspectos, características e vantagens da presente invenção irão se tornar aparentes com base na descrição detalhada seguinte das modalidades preferidas, a qual deve ser lida em ligação com os desenhos acompanhantes.
Petição 870190124947, de 28/11/2019, pág. 9/32
BREVE DESCRIÇÃO DOS DESENHOS
A FIG. 1 é um diagrama que ilustra uma modalidade ilustrativa de um sistema transmissor de sinal de vídeo e um sistema receptor do transmissor de sinal de vídeo;
A FIG. 2 é um diagrama que ilustra uma modalidade ilustrativa de um pacote de transporte; e
A FIG. 3 é um diagrama esquemático que ilustra uma modalidade ilustrativa de um método para extrair metadados de controle de reprodução a partir de um pacote de transporte para suportar a habilitação de uma função de controle de reprodução.
DESCRIÇÃO DETALHADA DA INVENÇÃO
A presente invenção está voltada para o suporte de uma função de controle de reprodução de vídeo em um dispositivo de reprodução de vídeo, tal como um computador, decodificador de sinais, aparelho de televisão, entre outros, usando as informações que são transmitidas como parte de um sinal de dados em pacotes proveniente de uma fonte tal como um provedor de satélite, por exemplo, DIRECTV, difusão de televisão pelo ar, companhia de cabo, provedor de transmissão contínua de mídia, transmissão pelo Protocolo Vídeo pela Internet, entre outros. As modalidades ilustrativas da presente invenção são descritas em relação ao uso de uma estrutura de transporte de dados que é utilizada por um provedor, tal como um provedor de satélite como a DIRECTV, ou de uma estrutura de transporte de dados que é compatível com o padrão de alta definição ATSC (veja “ATSC 53/A standard”, publicado em 4 de Outubro de 1995). Deve-se entender que as
Petição 870190124947, de 28/11/2019, pág. 10/32 modalidades descritas não são limitativas e que um indivíduo versado na técnica seria capaz de aplicar os princípios da presente invenção em outras metodologias de transmissão e estruturas de transporte.
Também deve ser entendido que a presente invenção pode ser implementada em várias formas de hardware, software, software armazenado em memória ROM (firmware), processadores de uso específico ou em uma combinação dos mesmos. De preferência, a presente invenção é implementada como uma combinação de hardware e software. Além disso, o software é implementado de preferência como um programa de aplicação incorporado de forma tangível em um dispositivo de armazenamento de programas. O programa de aplicação pode ser transferido para, e executado por uma máquina que compreende qualquer arquitetura adequada. De preferência, a máquina é implementada em uma plataforma de computador com hardwares tais como uma ou mais unidades de processamento central (CPU), uma memória de acesso aleatório (RAM) e interface(s) de entrada / saída (E/S). A plataforma de computador também inclui um sistema operacional e código de microinstrução. Os vários processos e funções descritos neste relatório podem ser parte do código de microinstrução ou parte do programa de aplicação (ou uma combinação dos mesmos) que é executada via o sistema operacional. Além disso, diversos outros dispositivos periféricos podem ser conectados à plataforma de computador, tal como um dispositivo de armazenamento de dados adicional e um dispositivo de impressão.
Deve-se adicionalmente entender que, pelo fato de
Petição 870190124947, de 28/11/2019, pág. 11/32 alguns componentes constituintes do sistema e etapas de método descritos nas Figuras acompanhantes serem implementados de preferência na forma de software, as conexões reais entre os componentes do sistema (ou as etapas de processo) podem divergir, dependendo da maneira em que a presente invenção é programada. Mediante os ensinamentos contidos neste relatório, um indivíduo versado na técnica relacionada será capaz de contemplar estas implementações ou configurações da presente invenção, ou seus similares.
A FIG. 1 apresenta uma vista de alto nível de um sistema de difusão de vídeo e recepção de vídeo 100 que será utilizado de acordo com uma modalidade da presente invenção. O sistema de difusão de vídeo 10 apresenta o conteúdo de vídeo 105 que proporciona o vídeo a ser transmitido pelo sistema de difusão de vídeo. De preferência, o conteúdo de vídeo 105 é o vídeo (e como opção a informação de áudio) que está armazenado em um dispositivo de armazenamento em massa (por exemplo, DVD, fita de vídeo, disco rígido) e é proporcionado por uma fonte de difusão em tempo real tal como uma câmara de vídeo ou por uma rede de dados capaz de transmitir informações de vídeo.
A informação de vídeo do conteúdo de vídeo 105 é codificada na forma de informação digital pelo codificador de vídeo 110, usando de preferência um padrão de compactação de vídeo tal como MPEG-2, H.261, H.264, entre outros. No caso do ATSC, utiliza-se MPEG-2 para compactar a informação de vídeo em Quadros Independentes (Quadros I). Quadros Bidirecionais (Quadros B) e Quadros Preditivos (Quadros P). Po
Petição 870190124947, de 28/11/2019, pág. 12/32 dem ser utilizados outros tipos de compactação de vídeo para compactar os dados de vídeo provenientes do codificador de vídeo 110 em um sinal de dados de vídeo compactado. Nota-se que a operação de compactar o vídeo pelo codificador de vídeo 110 é opcional e pode ser removida para uma difusão específica. Por exemplo, um difusor pode decidir transmitir um sinal de vídeo como uma série de quadros I não compactados, ou outro tipo de informação de vídeo não compactada.
O sinal de vídeo codificado proveniente do codificador de vídeo 110 é proporcionado para o codificador de transporte de vídeo 115 que codifica o sinal de vídeo em um sinal de dados em pacotes formado por uma série de pacotes de transporte de dados (fluxo de transporte). Em uma modalidade da presente invenção, o sinal de vídeo codificado proveniente do codificador de vídeo 110 é codificado em um fluxo de transporte composto de pacotes de transporte, conforme descritos no padrão ATSC 53/A e apresentado na FIG. 2. Tipicamente, um fluxo de transporte é utilizado para transmitir informações de vídeo, áudio ou auxiliares, onde cada fluxo de transporte é associado com um número de identificação de pacote particular, ou PID. Nota-se que podem ser utilizados outros tipos de esquemas de pacotes de transporte, tal como o Protocolo de Controle de Transporte (TCP), o Protocolo de Dados do Usuário (UDP) e outros do gênero.
De forma específica, o pacote de transporte da FIG. 2 representa um pacote de dados de cento e oitenta e oito bytes com um cabeçalho de quatro bytes. Os primeiro oito bits do cabeçalho representam um byte de sincronismo.
Petição 870190124947, de 28/11/2019, pág. 13/32
A segunda parte do pacote de dados é um valor de bit único que é um sinalizador de erro do pacote de transporte. A próxima parte do pacote de transporte representa um sinalizador indicador do início da unidade de carga útil que é um valor de bit único. Um sinalizador de prioridade de transporte é o próximo segmento do transporte, o qual consiste de um valor de um bit que indica se designou-se uma prioridade alta ou baixa para um pacote de transporte. Nota-se que este sinalizador de prioridade de transporte normalmente não é utilizado para uma difusão de programa de vídeo para uma transmissão de vídeo baseada em ATSC.
Os próximos treze bits são reservados para a informação de PID que identifica o fluxo de transporte ao qual pertence um pacote de transporte específico. Os próximos dois bits do cabeçalho de transporte representam um controle de embaralhamento de transporte (indicando se uma carga útil de pacote está embaralhada), com os dois bits seguintes indicando um controle de campo de adaptação (revelando se um cabeçalho de adaptação está predefinido e se o mesmo está acompanhado por uma carga útil no mesmo pacote de transporte). Os últimos quatro bits do cabeçalho representam um contador de continuidade que normalmente é aumentado de forma monotônica. O contador de continuidade pode ser utilizado para indicar a ordem dos pacotes de dados de transporte recebidos e para indicar se um pacote de dados de transporte está perdido.
Os outros cento e oitenta e quatro bits de um pacote de transporte são a carga útil do pacote representando
Petição 870190124947, de 28/11/2019, pág. 14/32 dados de áudio, dados de vídeo, dados auxiliares ou uma mistura de todos os três tipos de dados. Tipicamente, o conteúdo da carga útil é definido de acordo com os requerimentos de um difusor.
Referindo-se novamente ao sistema de difusão de vídeo 10 exibido na FIG. 1, o fluxo de transporte processado é proporcionado pelo codificador de transporte de vídeo 115 para o modulador / transmissor de vídeo 120 que modula o fluxo de transporte de vídeo em um sinal que é capaz de ser transmitido. O sinal modulado pode ser modulado através de uma técnica, como por exemplo, a modulação de amplitude em quadratura (QAM), modulação por deslocamento de fase em quadratura (QPSK), banda lateral vestigial (VSB) e outros do gênero, utilizados para transmitir um sinal de vídeo através de uma modalidade especificada tal como satélite, pelas ondas de ar, cabo, modem e seus semelhantes. Opcionalmente, o fluxo de transporte de vídeo é codificado para transmissão usando um formato tal como codificação em treliça, codificação de Reed Solomon, entre outros.
O sistema receptor de vídeo 20 (daqui em diante sistema receptor 20) representa um sistema de demodulação / decodificação de vídeo que é capaz de processar o sinal de dados transmitido pelo sistema de difusão de vídeo 10 em um sinal de vídeo que é capaz de ser reproduzido e exibido em um dispositivo de exibição. O receptor / demodulador de vídeo 150 representa o sistema de circuitos que recebe (via uma antena, antena de satélite, conexão de interface com a rede, entre outros) o sinal de dados transmitido a partir do
Petição 870190124947, de 28/11/2019, pág. 15/32 sistema de difusão de vídeo 10 e processa o sinal de dados em um fluxo de transporte de dados para operações adicionais. De preferência, o receptor / demodulador de vídeo 150 efetua operações que são o inverso das realizadas pelo modulador / transmissor 120 para transmitir um sinal de dados. Por exemplo, se um sinal de dados codificado em treliça foi modulado usando QAM, o receptor / demodulador de vídeo 150 demodularia o sinal de dados recebido usando uma demodulação baseada no QAM e a técnica de decodificação em treliça em um fluxo de transporte a partir de um subsistema de camada de ligação. Deve-se apreciar que podem ser escolhidas técnicas de demodulação e decodificação diferentes com base nos requerimentos do sistema receptor 20.
O decodificador de transporte 160 recebe o fluxo de transporte decodificado a partir do demodulador do receptor de vídeo 150 e processa os pacotes de transporte recebidos em informações de vídeo codificado e informação representando dados de controle de reprodução. Como será explicado posteriormente no texto do pedido, o decodificador de transporte 160 lê a informação incorporada ao cabeçalho ou à carga útil do pacote de transporte para auxiliar o sistema receptor 20 em uma função de controle de reprodução. Exemplos da informação extraída pelo decodificador de transporte 160 são descritos posteriormente no texto deste relatório descritivo.
O decodificador de vídeo 165 recebe os dados processados a partir do decodificador de transporte de vídeo 160. De preferência, o decodificado de vídeo 165 obtém os
Petição 870190124947, de 28/11/2019, pág. 16/32 dados processados e decodifica tais dados em informação de vídeo que é capaz de ser exibida no dispositivo de exibição
173 (representado por uma televisão, monitor, ou parecido). A operação de decodificação de vídeo realizada pelo decodificador de vídeo 165 é a operação inversa realizada pelo codificador de vídeo 110. Por exemplo, se os dados processados forem codificados na forma de vídeo MPEG-2, o decodificador de vídeo 165 decodificaria o vídeo MPEG-2 em um sinal de vídeo que é capaz de ser exibido no dispositivo de exibição 173. A operação de decodificação realizada pelo decodificador de vídeo 165 depende do esquema de codificação utilizado para codificar os dados de vídeo. Opcionalmente, o decodificador de vídeo 165 também decodifica a informação de áudio proveniente dos dados processados, recebida a partir do decodificador de transporte 160. Esta informação de áudio decodificada é capaz de ser emitida para o alto-falante
174 pelo decodificador de vídeo 165 na forma de som.
A memória local 175, acoplada ao decodificador de transporte 160, é utilizada para armazenar a informação que é extraída dos pacotes de transporte recebidos para suportar uma função de controle de reprodução pelo sistema receptor 20. Esta informação pode ser uma tabela de metadados que é formada com base na informação que é extraída dos pacotes de transporte pelo decodificador de transporte 160, como será descrito posteriormente neste relatório descritivo.
O dispositivo de armazenamento 180 é condicionado para armazenar os fluxos de transporte recebidos a partir do decodificador de transporte 160, os fluxos de transporte dePetição 870190124947, de 28/11/2019, pág. 17/32 codificados recebidos a partir do decodificador de transporte 160 e os dados de vídeo decodificados recebidos a partir do decodificador de vídeo 165. De preferência, o dispositivo de armazenamento 180 é um dispositivo de armazenamento tal como um disco rígido, memória de acesso aleatório, cartão de memória flash, disco versátil digital, sistema de fita e seus semelhantes. Além de armazenar dados de vídeo e fluxos de transporte, o dispositivo de armazenamento 180 é condicionado para suportar funções de controle de reprodução tais como avanço rápido, retroceder, pausar, saltar para frente, saltar para trás, entre outras.
O processador do sistema 155 é um microprocessador utilizado pelo sistema receptor 20 para controlar os componentes do sistema receptor 20 descrito acima. Em uma modalidade opcional da presente invenção, o processador do sistema 165 é combinado com o decodificador de transporte 100.
Ao transmitir um sinal digital como uma série de pacotes de transporte de dados, o sistema transmissor 10 e o sistema receptor 20 são capazes de suportar funções de controle de reprodução pelo uso de seções específicas de tais pacotes de transporte de dados para indicar informações sobre os dados de vídeo sendo distribuídos em tais pacotes de transporte de dados. Estes dados representando os metadados de controle de reprodução são inseridos em um pacote de transporte (no cabeçalho, na carga útil ou em ambos) pelo codificador de transporte 115. De forma semelhante, quando os dados digitais são processados pelo sistema receptor 20, o decodificador de transporte 160 é configurado para extrair
Petição 870190124947, de 28/11/2019, pág. 18/32 tais metadados de controle de reprodução de um pacote de transporte no qual podem residir tais metadados.
Em seguida, os metadados extraídos são utilizados pelo sistema receptor 20 para formar uma tabela de metadados que correlaciona metadados de controle de reprodução e a informação que está sendo distribuída para, e processada pelo sistema receptor 20. Por exemplo, a TABELA 1 representa uma modalidade ilustrativa de uma tabela de metadados de controle de reprodução que é utilizada para suportar uma função de 10 controle. No presente exemplo, a TABELA 1 indica a informação de posição de tempo dos quadros I que são recebidos em um fluxo de transporte de dados em pacotes, onde as posições de tempo são armazenadas como entradas na tabela, embora outras informações relacionadas ao controle de reprodução pos15 sam ser armazenadas na tabela.
TABELA I
TIPO DE QUADRO POSIÇÃO DE TEMPO (em segundos)
I 1.27
I 2.54
I 3.71
I 4.11
I 5.25
I 6.11
Os valores utilizados para criar a tabela contendo metadados de controle de reprodução armazenados de preferên
Petição 870190124947, de 28/11/2019, pág. 19/32 cia na memória local 175 pelo decodificador de transporte 160. Além disso, o dispositivo de armazenamento 180 pode ser opcionalmente utilizado para armazenar dados representando o fluxo de transporte, a informação de vídeo codificada ou a informação de vídeo decodificada que é acessada pelo processador do sistema 155 para ajustar uma função de controle de reprodução.
De acordo com uma modalidade da invenção, um fluxo de transporte, quando recebido pelo sistema receptor 20, é processado para criar o conteúdo na TABELA 1 (conforme armazenado na memória local 175) e o conteúdo do dado de vídeo do fluxo de transporte é armazenado como vídeo codificado no dispositivo de armazenamento 180, conforme descrito acima. Quando o sistema receptor 20 opera em um modo de controle de reprodução, tal como avanço rápido, o processador do sistema 155 acessa os metadados de controle de reprodução na memória local 175 para determinar a posição de tempo dos quadros I que estão armazenados no dispositivo de armazenamento 180. Por acessar e decodificar somente os quadros I armazenados no dispositivo de armazenamento 180 (na ordem de 1.27 segundos, 2.54 segundos, 3.71 segundos, entre outros), o processador do sistema 155 sabe quais dados de vídeo deverá apresentar ao decodificador de vídeo 165, sem ter de decodificar os quadros B e P que também residem como parte dos dados de vídeo codificados armazenados e são desnecessários para uma operação de controle de reprodução de avanço rápido. Além disso, o processador do sistema 155 pode utilizar outros metadados armazenados na tabela para suportar funções, como
Petição 870190124947, de 28/11/2019, pág. 20/32 por exemplo “saltar para frente cinco minutos”, através da consulta dos códigos de tempo dos pontos de entrada e das contagens de bytes correspondentes. Além disso, por consultar a tabela de metadados, o processador do sistema 155 pode localizar todos os inícios e finais do programa e apresentar detalhes textuais sobre o conteúdo do programa (tal como listar o início, o fim e a duração de tempo de um programa). Outras funções de controle de reprodução e aplicações podem ser implementadas pelos versados na técnica de acordo com os princípios da presente invenção.
Ao transmitir os metadados de controle de reprodução como parte de um fluxo de transporte a partir do sistema transmissor 10 para o sistema receptor 20, uma modalidade da presente invenção substitui este bit de prioridade de transporte (de um pacote de transporte baseado em ATSC) insere metadados de controle de reprodução no lugar, já que este bit não é utilizado normalmente em ATSC (ou em fluxos DIRECTV). O inventor da presente invenção reconhece que o cabeçalho de transporte de um pacote de transporte serve como um lugar ideal para inserir metadados de controle de reprodução porque os cabeçalhos de pacote de transporte (e portanto, o bit de prioridade de transporte) normalmente não são criptografados durante a transmissão. Portanto, um decodificador pode fazer o uso de metadados de controle de reprodução sem ter de suportar um subsistema de segurança.
Referindo-se novamente ao uso do bit de prioridade de transporte como a localização dos metadados de controle de reprodução, os bits que são transmitidos como bits de
Petição 870190124947, de 28/11/2019, pág. 21/32 prioridade de transporte podem ser montados em bytes, e tais bytes podem ser montados em mensagens completas. Então, múltiplas mensagens irão compreender metadados para uma PID particular e o fluxo elementar ao qual corresponde a PID.
Embora possa parecer que um único bit do grupo de bits pode não ser suficiente para gerar metadados de controle de reprodução significativos, o inventor nota que para um fluxo de vídeo de 4M bps, serão transmitidos mais de quatro mil pacotes por segundo (comparado aos 2650 pacotes de dados 10 para um sistema de distribuição baseado em ATSC). Portanto, ao utilizar o bit de prioridade de transporte separadamente, centenas de bytes de metadados de controle de reprodução são capazes de serem recebidos e utilizados pelo sistema receptor 20. Deve-se apreciar que outras partes de um pacote de 15 transporte, incluindo outras seções do cabeçalho, carga útil, o cabeçalho e a carga útil e outros tipos de pacotes de transporte podem ser utilizados para transmitir metadados relacionados ao controle de reprodução, de acordo com os princípios da presente invenção.
A TABELA 2 representa uma modalidade ilustrativa de uma mensagem apresentando metadados de controle de reprodução que é montada a partir dos dados de bit de prioridade que são extraídos de uma série de pacotes de transporte de dados.
TABELA 2
Petição 870190124947, de 28/11/2019, pág. 22/32
Elemento Formato Valor
Start Code Bits '00000000 00000000 00000001'
Function Byte '0000 0001'
ByteCount Byte N = bytes de Payload
Payload N x bytes Variável
Fill Y x bits Repete-se 1 até o próximo código inicial
A TABELA 3 representa uma modalidade ilustrativa de uma mensagem alternativa apresentando metadados de controle de reprodução que é montada a partir dos dados de bit de prioridade que são extraídos de uma série de pacotes de transporte de dados.
TABELA 3
Elemento Formato Valor
Start Code Bits '00000000 00000000 00000001'
Command Byte Conforme definido por COMMAND na TABELA 5
Data N x bytes Conforme definido por DATA na TABELA 5
Fill Y x bits 1, repetido Y vezes, até o próximo código inicial
Se um pacote de transporte recebido for perdido ou contiver erros durante a recepção, a mensagem de metadados atual após este momento seria suspeita, e a aquisição adiciPetição 870190124947, de 28/11/2019, pág. 23/32 onal das mensagens irá parar até ser detectado um novo código inicial. Em uma modalidade opcional da presente invenção, a sintaxe de uma payload é construída de modo que a evitar a ocorrência de emulação do código inicial. De forma específica, isso é realizado pela inserção de um bit marcador (de valor '1') entre os elementos de sintaxe que compõe a mensagem. No final dos dados, o valor '1' é repetido até o próximo código inicial.
Se os metadados de controle de reprodução puderem ser alinhados a uma transmissão, um sinalizador do cabeçalho de transporte, tal como um bit de Pacote Limite ou um Indicador de Início de Unidade de Carga Útil (como utilizado para pacotes de transporte baseados em ATSC), um sinalizador do cabeçalho de transporte pode então servir como um indicador inicial para indicar a presença de uma mensagem de metadados (que pode servir como metadados para suportar uma função de controle de reprodução). Sob tal condição, as transmissões de metadados opcionalmente se alteram para um formato conforme apresentado na TABELA 4, onde os dados não têm de ser restringidos a fim de evitar a ativação não intencional de um código inicial. De forma similar, pode-se definir um sinalizador indicador no cabeçalho de um pacote de transporte para indicar a presença de metadados relacionados ao controle de reprodução na carga útil do pacote de transporte.
TABELA 4
Petição 870190124947, de 28/11/2019, pág. 24/32
Elemento Formato Valor
Function Byte Conforme definido por COMMAND, co- mo apresentado na TABELA 5
Payload N x bytes Conforme definido por DATA, como apresentado na TABELA 5
Fill Y x bits “1”, repetido Y vezes, até a próxima mensagem
Sob o formato de alinhamento específico, conforme apresentado na TABELA 4, infere-se uma nova semântica que varia em função dos dados dos quadros de vídeo específicos que estão contidos dentro de uma carga útil de transporte. Por exemplo, um tipo de dado indicando o “código de tempo de programa” de um determinado quadro pode ser montado a partir dos mesmos pacotes de transporte que contêm o dito quadro. Esse tipo de correspondência pode ser obtido para grande parte, senão todos os quadros transmitidos em um multíplex de transporte.
O que vem a seguir apresenta uma estrutura geral dos campos COMMAND e DATA que podem ser utilizados para transmitir metadados de controle de reprodução, como utilizados para as estruturas de transporte apresentadas nas Tabelas 2 a 4. Nota-se que os comandos generalizados COMMAND e DATA podem ser concatenados um ao outro e transmitidos como uma seqüência de vários comandos e dados até que o tamanho da variável ByteCount seja detectado, até que os bits “fill” sejam detectados ou até que o próximo código inicial seja detectado. Os tipos COMMAND e DATA são apresentados na
Petição 870190124947, de 28/11/2019, pág. 25/32
TABELA 5, a qual pode ser utilizada para descrever atributos de informação de vídeo em um pacote de transporte de dados.
TABELA 5
COMMAND DATA Significado dos dados / atributos associados
0000 0000 Proibido
0000 0001 Proibido
0000 XX1X Reservado
0000 X1XX Reservado
0000 1XXX Reservado
0001 0000 6 bytes Valor de “time code” no início do quadro atual
0001 0001 6 bytes Valor de time code” no início do programa
0001 0010 6 bytes Valor de time code” na última descontinuidade
0001 0011 6 bytes Valor de time code” no final do programa
0001 0100 6 bytes Valor da duração do programa atual
0001 0101 6 bytes Taxa de Bits do Vídeo (Máxima)
0001 0110 6 bytes Valor do tamanho do quadro atual, em bytes
0001 0111 6 bytes Valor do tamanho do programa atual, em bytes
0001 1XXX 6 bytes Reservado
0010 0000 1 byte Tipo do quadro atual, definido como
Petição 870190124947, de 28/11/2019, pág. 26/32
segue:
0000 0000 = proibido
0000 0001 = quadro I
0000 0010 = quadro P
0000 0011 = quadro B
0000 0100 = quadro chave do modo de controle
0000 0101 = ponto de acesso aleatório
0000 0110 = quadro de referência de decodificação
0000 0111 = quadro descontínuo
xxxx 1xxx = Reservado
0010 0001 1 byte Valor de (PTS-DTS) / (PTS[quadro+1]-PTS[quadro])
0010 0010 1 byte Valor do número de programa atual
0010 0011 1 byte Quadro Fixo; número de segundos a exibir
0010 X1XX 1 byte Reservado
0010 1XXX 1 byte Reservado
0011 0000 8 bytes Valor do byte pgm ptr no início do quadro atual
0011 0001 8 bytes Valor do byte pgm ptr no início do programa
Petição 870190124947, de 28/11/2019, pág. 27/32
0011 0010 8 bytes Valor do byte pgm ptr no fim do programa
0011 0011 8 bytes Reservado
0011 X1XX 8 bytes Reservado
0011 1XXX 8 bytes Reservado
0100 0000 6 bytes Valor PTS do quadro atual
0100 0001 6 bytes Valor DTS do quadro atual
0100 0010 6 bytes Valor PCR no início da localização do quadro atual
0100 0011 6 bytes Valor do PCR no início da próxima descontinuidade
0100 X1XX 6 bytes Reservado
0100 1XXX 6 bytes Reservado
1111 0000 1 byte Número de bytes de texto de descrição do programa a seguir
1111 0001 1 byte Número de bytes de dados XML a seguir
1111 1111 Fim da carga útil; utilizado opcionalmente,· segue o enchimento
Todos os outros valores de COMMAND são reservados e devem ser seguidos por um byte de dados que descreve o número de bytes de dado adicionais a seguir, como um operando para o comando.
O uso de comandos COMMAND e DATA, conforme apresentado na TABELA 5, é opcional, por exemplo, a ausência de uma indicação de um quadro I não quer dizer que o presente quadro não é um quadro I. Entretanto, para COMMAND e DATA
Petição 870190124947, de 28/11/2019, pág. 28/32 declarados explicitamente em um pacote de transporte, o significado de tais COMMANDS e DATA é verdadeiro.
Usando a metodologia descrita acima, uma tabela de metadados deve ser construída próximo (ou até mesmo igual) à taxa em que os quadros de vídeo são recebidos pelo sistema receptor 20. por exemplo, caso sejam capturados somente cinco minutos de vídeo e os mesmos sejam armazenados no dispositivo de armazenamento 180, os metadados de controle de reprodução para estes mesmos cinco minutos também são armazenados no dispositivo de armazenamento 180.
Opcionalmente, de modo a usar o dispositivo de armazenamento 180, um fluxo de transporte parcial pode ser armazenado onde os pacotes de dados que não contribuem para um programa desejado são descartados pelo sistema receptor 20. O uso desta metodologia requer um grau de decodificação do fluxo de transporte pelo decodificador de transporte 160. Durante esse processo de decodificação opcional, pode-se extrair os metadados de controle de reprodução e armazená-los em outro lugar a partir do fluxo de transporte parcial. Dessa forma, o armazenamento de um fluxo de transporte pode ser manipulado pelo dispositivo de armazenamento 180 e pelos componentes relacionados do sistema de armazenamento, permitindo criptografia adicional ou reorganização de dados para facilitar a recuperação e reprodução ideal dos dados de vídeo. Portanto, os metadados de controle de reprodução podem continuar abertos e locais para o sistema receptor 20 para processos adicionais de busca, onde são buscados parâmetros de vídeo nos metadados em vez de no próprio fluxo de transPetição 870190124947, de 28/11/2019, pág. 29/32 porte. Quando os metadados apropriados são encontrados, podem ser gerados comandos simples de índice de arquivos para subsistemas de armazenamento, tal como o dispositivo de armazenamento 180.
Como uma modalidade opcional adicional da presente invenção, a informação relacionada aos metadados de controle de reprodução pode ser colocada em uma estrutura de fluxo elementar em pacotes (PES) que é inserida na carga útil de um ou mais pacotes de transporte de uma PID única. Neste caso, a adição de um campo marca de tempo de apresentação (PTS) é utilizada para identificar um quadro único ao qual se aplica um determinado pacote PES. Esta modalidade opcional da invenção suporta a transmissão de metadados de controle de reprodução associada com informação de guia de canal ou a transmissão da informação específica de programa (PSI) que identifica um programa ao qual se aplicam os metadados de controle de reprodução.
A FIG. 3 ilustra um método 300 para extrair e utilizar metadados de controle de reprodução a partir de um fluxo de transporte recebido, de acordo com uma modalidade da presente invenção. A etapa 305 é uma etapa opcional para identificar se os dados que podem ser utilizados como metadados de controle de reprodução existem dentro de um pacote de transporte. Como explicado acima, a informação que pode ser utilizada como metadados de controle de reprodução pode residir em um cabeçalho de pacote de transporte, na carga útil de um pacote de transporte, abarcar vários pacotes de transporte ou uma combinação de todas essas possibilidades.
Petição 870190124947, de 28/11/2019, pág. 30/32
Além disso, a identificação dos metadados pode ser realizada por reservar um determinado sinalizador que indica a presença dos metadados de controle de reprodução, por utilizar vários comandos e formatos de dados (como descrito acima), ou por outros procedimentos de acordo com os princípios da presente invenção.
A etapa 310 é a extração da informação que pode ser utilizada como metadados de controle de reprodução dos pacotes de transporte recebidos. Tipicamente, o decodificador de transporte 160 realiza esta etapa, mas existem modalidades alternativas da etapa 310 que podem ser implementadas por outros componentes do sistema receptor 20. Por exemplo, um fluxo de transporte recebido pode ser arquivado no dispositivo de armazenamento 180 até um momento posterior em que o decodificador de transporte 180 analisa tal fluxo de dados em relação à presença da informação que pode ser utilizada como metadados de controle de reprodução. Na etapa 315, a informação extraída que representa os metadados de controle de reprodução é armazenada em uma memória, tal como a memória local 175 ou o dispositivo de armazenamento 180. De preferência, tal informação de metadados é armazenada em uma tabela, conforme descrito acima.
A etapa 320 diz que se uma função de controle de reprodução for ativada durante a reprodução do vídeo, um dispositivo de reprodução de vídeo (tal como o dispositivo receptor 20) acessa os dados armazenados representando os metadados de controle de reprodução e utiliza tal informação para implementar uma função de controle de reprodução dese
Petição 870190124947, de 28/11/2019, pág. 31/32 jada. Como descrito acima, se um usuário desejasse uma função de controle de reprodução de avanço rápido, o dispositivo de reprodução de vídeo (20) localizaria as posições de tempo dos quadros I armazenados no dispositivo de armazenamento 180 e emitiria somente tais quadros durante a operação de avanço rápido. Outras funções de controle de reprodução devem ser implementadas pelo uso dos metadados de controle de reprodução armazenados, de acordo com os princípios da presente invenção.
Deve-se apreciar que, embora a presente invenção seja descrita em relação a um sistema de comunicações baseado no Advanced Television Systems Committee (ATSC), a presente invenção pode ser empregada com qualquer sistema de comunicações digitais baseado em pacotes.
Apesar de as modalidades ilustrativas terem sido descritas neste documento com referência aos desenhos acompanhantes, deve-se entender que a presente invenção não está limitada a estas modalidades exatas e que um indivíduo versado na técnica relacionada pode realizar várias outras alterações e modificações na mesma sem divergir do escopo da invenção. Pretende-se que todas estas alterações e modificações sejam incluídas dentro do escopo da invenção, conforme definido pelas reivindicações anexas.

Claims (13)

  1. REIVINDICAÇÕES
    1. Método, adaptado para ser executado em um dispositivo de codificação de vídeo, CARACTERIZADO por compreender :
    inserir metadados (115) em pelo menos dois pacotes de transporte de uma pluralidade de pacotes de transporte de um fluxo de dados em pacote que codifica informação de vídeo, em que os ditos metadados dos ditos pelo menos dois pacotes de transporte são adaptados para serem montados em bytes representando pelo menos uma mensagem adaptada para suportar uma função de controle de reprodução para a dita informação de vídeo.
  2. 2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que os ditos metadados são inseridos em cabeçalhos de transporte dos ditos pelo menos dois pacotes de transporte de dados.
  3. 3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que os ditos metadados são inseridos nos bits de prioridade de transporte dos ditos cabeçalhos de pacote de transporte dos ditos pelo menos dois pacotes de transporte.
  4. 4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que um sinalizador indicador é ativado em cabeçalhos de transporte dos ditos pelo menos dois pacotes de transporte a fim de indicar que os ditos metadados estão presentes em uma carga útil dos ditos pelo menos dois pacotes de transporte.
  5. 5. Método, de acordo com a reivindicação 1,
    Petição 870190014010, de 11/02/2019, pág. 12/15
    CARACTERIZADO pelo fato de que a dita mensagem é selecionada a partir de pelo menos um dentre: um código de tempo de um quadro atual, um código de tempo de um início de programa, um código de tempo de uma última descontinuidade, um código de tempo de um fim de programa, informação relacionada ao tamanho do quadro atual, informação relacionada ao tamanho do programa atual, informação indicando um quadro de vídeo no dito pelo menos um pacote de transporte, um quadro chave do modo de controle, um quadro de referência de decodificação, um quadro descontínuo e informação representando um quadro fixo e o número de segundos em que o dito quadro deve ser exibido.
  6. 6. Método, adaptado para ser realizado em um dispositivo de decodificação de vídeo, CARACTERIZADO pelo dito método compreender:
    processar uma pluralidade de pacotes de transporte (160) do fluxo de dados em pacotes que codifica informação de vídeo, o dito processamento compreendendo montar metadados extraídos de pelo menos dois pacotes de transporte da dita pluralidade de pacotes de transporte em bytes, representando pelo menos uma mensagem utilizada para suportar uma função de controle de reprodução para a dita informação de vídeo.
  7. 7. Método, de acordo com a reivindicação 6, CARACTERIZADO por compreender ainda acessar a dita mensagem para implementar a dita função de controle de reprodução.
  8. 8. Método, de acordo com a reivindicação 6, CARACTERIZADO por compreender ainda armazenar dados da dita
    Petição 870190014010, de 11/02/2019, pág. 13/15 pluralidade de pacotes de transporte em um dispositivo de armazenamento, em que os ditos dados armazenados são pelo menos um dentre: os pacotes de transporte, informação de vídeo decodificada dos ditos pacotes de transporte, informação de vídeo que é decodificada dos ditos pacotes de transporte e é selecionada em vista da mensagem representada pelos ditos metadados extraídos.
  9. 9. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que os ditos metadados são extraídos dos ditos pelo menos dois pacotes de transporte em vista de um sinalizador indicador nos ditos pelo menos dois pacotes de transporte.
  10. 10. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que os ditos metadados são extraídos de bits únicos localizados em cabeçalhos dos ditos pelo menos dois pacotes de transporte.
  11. 11. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que o dito processamento compreende ainda armazenar os ditos metadados extraídos em uma tabela.
  12. 12. Dispositivo de decodificação de vídeo,
    CARACTERIZADO por compreender:
    meios para processar uma pluralidade de pacotes de transporte (160) de um fluxo de dados em pacotes que codifica informação de vídeo, o dito processamento compreendendo montagem de metadados extraídos de pelo menos dois pacotes de transporte da dita pluralidade de pacotes de transporte em bytes, representando pelo menos uma mensagem usada para
    Petição 870190014010, de 11/02/2019, pág. 14/15 suportar uma função de controle de reprodução para a dita informação de vídeo.
  13. 13. Dispositivo de codificação de vídeo
    CARACTERIZADO por compreender:
    meios para inserir metadados em pelo menos dois pacotes de transporte de uma pluralidade de pacotes de transporte de um fluxo de dados em pacote que codifica informação de vídeo, em que os ditos metadados dos ditos pelo menos dois pacotes de transporte são adaptados para serem montados em bytes representando pelo menos uma mensagem adaptada para suportar uma função de controle de reprodução para a dita informação de vídeo.
BRPI0517365A 2004-09-23 2005-09-23 inserção de metadados para controle de reprodução em fluxo de transporte de vídeo BRPI0517365B1 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US61262404P 2004-09-23 2004-09-23
PCT/US2005/034196 WO2006034464A1 (en) 2004-09-23 2005-09-23 Inserting metadata for trick play in video transport stream

Publications (2)

Publication Number Publication Date
BRPI0517365A BRPI0517365A (pt) 2008-10-07
BRPI0517365B1 true BRPI0517365B1 (pt) 2019-12-17

Family

ID=35614586

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0517365A BRPI0517365B1 (pt) 2004-09-23 2005-09-23 inserção de metadados para controle de reprodução em fluxo de transporte de vídeo

Country Status (6)

Country Link
US (1) US7996871B2 (pt)
EP (1) EP1792491B1 (pt)
JP (1) JP4980913B2 (pt)
CN (1) CN101027909B (pt)
BR (1) BRPI0517365B1 (pt)
WO (1) WO2006034464A1 (pt)

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060227775A1 (en) * 2005-04-12 2006-10-12 Arul Thangaraj System, method, and apparatus for embedding personal video recorder functions in transport packets
JP4438798B2 (ja) * 2005-04-22 2010-03-24 ソニー株式会社 記録装置および記録方法、再生装置および再生方法、プログラム、並びに記録媒体
KR100698277B1 (ko) * 2005-07-15 2007-03-22 엘지전자 주식회사 영상표시장치 및 이를 이용한 방송신호 재생 방법
US8218546B2 (en) * 2005-11-10 2012-07-10 Broadcom Corporation Interleaved processing of dropped packets in a network device
EP1999883A4 (en) 2006-03-14 2013-03-06 Divx Llc FEDERATED DIGITAL RIGHTS MANAGEMENT SYSTEM COMPRISING CONFIDENCE SYSTEMS
US8929360B2 (en) * 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
US20080250101A1 (en) * 2007-04-05 2008-10-09 Matsushita Electric Industrial Co., Ltd. Multimedia data transmitting apparatus and multimedia data receiving apparatus
US7950039B2 (en) * 2007-04-05 2011-05-24 Panasonic Corporation Multimedia data transmitting apparatus and multimedia data receiving apparatus
US7941823B2 (en) * 2007-04-16 2011-05-10 Time Warner Cable Inc. Transport stream encapsulated trick modes
JP2008294638A (ja) 2007-05-23 2008-12-04 Sony Corp 伝送システム、記録装置、伝送方法、記録方法、およびプログラム
US7929698B2 (en) * 2007-06-15 2011-04-19 Sony Corporation Selective encryption to enable trick play with enhanced security
US7890986B2 (en) * 2007-06-19 2011-02-15 Broadcom Corporation System and method for reducing channel change time
KR101432994B1 (ko) 2007-08-13 2014-08-22 삼성전자주식회사 미디어 객체 기반 메타데이터의 생성 방법, 재생 방법 및그 장치
JP5547649B2 (ja) * 2007-11-28 2014-07-16 ソニック アイピー， インコーポレイテッド 部分的に利用可能なマルチメディアコンテンツの再生のためのシステム及び方法
GB2472221B (en) * 2009-07-28 2015-08-12 Fujitsu Ltd Streaming priority in communication systems
US9277183B2 (en) * 2009-10-13 2016-03-01 Sony Corporation System and method for distributing auxiliary data embedded in video data
BR112012011581A2 (pt) * 2009-11-04 2017-09-19 Huawei Tech Co Ltd sistema e método para streaming de conteúdo de mídia
JP5652642B2 (ja) * 2010-08-02 2015-01-14 ソニー株式会社 データ生成装置およびデータ生成方法、データ処理装置およびデータ処理方法
US9237363B2 (en) * 2011-02-12 2016-01-12 Openwave Mobility, Inc. Dynamic injection of metadata into flash video
CN102739975B (zh) * 2011-05-17 2017-09-12 新奥特（北京）视频技术有限公司 一种通过数据阵列实现动态二维字幕的方法及系统
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) * 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US9043832B2 (en) * 2012-03-16 2015-05-26 Zhongshan Innocloud Intellectual Property Services Co., Ltd. Early warning system, server and method
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
WO2016076655A1 (ko) * 2014-11-13 2016-05-19 엘지전자 주식회사 트릭 플레이 서비스에서 비디오와 서브타이틀의 동기화를 위한 방송 신호를 송수신하는 방법 및 장치
CA2973103C (en) * 2015-01-06 2020-08-04 Arris Enterprises Llc A method for efficient processing of btp enabled mpeg4 stream
US9510025B1 (en) * 2015-06-03 2016-11-29 Mobitv, Inc. Live consecutive ad insertion
BR112018009422A8 (pt) 2015-11-09 2019-02-26 Thomson Licensing método e dispositivo para adaptar o conteúdo de vídeo decodificado às características de um display a partir de fluxos elementares
CN106331824B (zh) * 2016-08-31 2020-02-14 杭州当虹科技股份有限公司 一种以可变速率播放流媒体视频文件的方法
KR102413839B1 (ko) 2017-11-15 2022-06-28 삼성전자 주식회사 컨텐츠 제공장치, 그 제어방법 및 기록매체
US10382821B1 (en) * 2018-03-15 2019-08-13 Rovi Guides, Inc. Methods and systems for selecting a destination for storage of a media asset based on wireless access likelihood
US10382812B1 (en) * 2018-03-15 2019-08-13 Rovi Guides, Inc. Methods and systems for selecting a destination for storage of a media asset based on trick-play likelihood
CN115623282B (zh) * 2022-12-02 2023-04-07 杭州海康威视数字技术股份有限公司 加密视频的定点播放方法、装置、电子设备及存储介质

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3603364B2 (ja) * 1994-11-14 2004-12-22 ソニー株式会社 ディジタルデータ記録／再生装置及び方法
US6445738B1 (en) * 1996-04-25 2002-09-03 Opentv, Inc. System and method for creating trick play video streams from a compressed normal play video bitstream
US6065050A (en) * 1996-06-05 2000-05-16 Sun Microsystems, Inc. System and method for indexing between trick play and normal play video streams in a video delivery system
US6510554B1 (en) * 1998-04-27 2003-01-21 Diva Systems Corporation Method for generating information sub-streams for FF/REW applications
US6460086B1 (en) 1998-12-01 2002-10-01 Sun Microsystems, Inc. Method and apparatus for delivery of a bytecode embedded within a transport stream
EP1058265A1 (en) * 1999-05-29 2000-12-06 Deutsche Thomson-Brandt Gmbh Method and apparatus for reverse playback of a digital data stream
EP1148727A1 (en) * 2000-04-05 2001-10-24 THOMSON multimedia Method and device for decoding a digital video stream in a digital video system using dummy header insertion
IL132859A (en) 1999-11-10 2008-07-08 Nds Ltd Data stream processing system
AU2001229644A1 (en) * 2000-01-27 2001-08-07 Suzanne M. Berberet System and method for providing broadcast programming, a virtual vcr, and a video scrapbook to programming subscribers
JP2002016919A (ja) 2000-04-28 2002-01-18 Sony Corp 情報送信方法及び装置、情報受信方法及び装置、情報記録方法及び装置、並びに、情報記録再生方法及び装置
AU2000248144A1 (en) * 2000-05-02 2002-02-25 General Instrument Corporation Method and apparatus for enabling random access to individual pictures in an encrypted video stream
JP4538908B2 (ja) * 2000-06-14 2010-09-08 ソニー株式会社 データ変換装置及び方法
US6871006B1 (en) * 2000-06-30 2005-03-22 Emc Corporation Processing of MPEG encoded video for trick mode operation
JP4331876B2 (ja) * 2000-09-18 2009-09-16 パナソニック株式会社 デジタル信号記録再生システム
KR20020032803A (ko) * 2000-10-27 2002-05-04 구자홍 스트리밍 서비스를 위한 파일 구조
JP2002325230A (ja) * 2001-04-26 2002-11-08 Sony Corp データ記録装置及び方法、データ再生装置及び方法
US8923688B2 (en) * 2001-09-12 2014-12-30 Broadcom Corporation Performing personal video recording (PVR) functions on digital video streams
US6738980B2 (en) * 2001-11-15 2004-05-18 Industrial Technology Research Institute Methods and systems for video streaming with VCR functionality
US7231178B2 (en) * 2001-12-11 2007-06-12 Virtual Satellite Corp. Virtual channel satellite communication system with improved bandwidth efficiency
KR100614371B1 (ko) 2001-12-22 2006-08-18 주식회사 휴맥스 디지털 방송 스트림의 변속재생 제어정보 기록방법과,그에 따른 디지털 방송수신기에서의 변속재생 제어방법
US7274857B2 (en) * 2001-12-31 2007-09-25 Scientific-Atlanta, Inc. Trick modes for compressed video streams
US20030123657A1 (en) * 2001-12-31 2003-07-03 General Instrument Corporation Methods and apparatus for simultaneously decrypting multiple services received on separate multiplexed transport streams
JP2003264804A (ja) 2002-03-12 2003-09-19 Hitachi Ltd データ配信システム、データ配信装置、デジタル受信機、データ配信方法
US6847780B2 (en) * 2002-03-28 2005-01-25 Sony Corporation Trick-mode stream creation for personal video recording functions
US7539391B2 (en) * 2002-06-27 2009-05-26 Nxp B.V. Method and apparatus for trick-mode support of audio/video/data streams with conditional access
KR100447200B1 (ko) * 2002-07-30 2004-09-04 엘지전자 주식회사 Ｐｖｒ 지원 비디오 디코딩 시스템
US7826718B2 (en) * 2002-08-09 2010-11-02 Broadcom Corporation Method and apparatus to facilitate the efficient implementation of trick modes in a personal video recording system
US7739715B2 (en) * 2003-06-24 2010-06-15 Microsoft Corporation Variable play speed control for media streams
US20050022245A1 (en) * 2003-07-21 2005-01-27 Ramesh Nallur Seamless transition between video play-back modes
US20050262529A1 (en) * 2004-05-20 2005-11-24 Raja Neogi Method, apparatus and system for remote real-time access of multimedia content
US20060037057A1 (en) * 2004-05-24 2006-02-16 Sharp Laboratories Of America, Inc. Method and system of enabling trick play modes using HTTP GET

Also Published As

Publication number Publication date
BRPI0517365A (pt) 2008-10-07
CN101027909A (zh) 2007-08-29
WO2006034464A1 (en) 2006-03-30
EP1792491B1 (en) 2021-06-02
US7996871B2 (en) 2011-08-09
JP2008514141A (ja) 2008-05-01
US20080120637A1 (en) 2008-05-22
EP1792491A1 (en) 2007-06-06
CN101027909B (zh) 2013-03-13
JP4980913B2 (ja) 2012-07-18

Similar Documents

Publication Publication Date Title
BRPI0517365B1 (pt) inserção de metadados para controle de reprodução em fluxo de transporte de vídeo
US9843827B2 (en) Physical layer signalling for digital broadcast system
US9854279B2 (en) Transport stream packet header compression
US6788710B1 (en) Auxiliary data insertion in a transport datastream
ES2820859T3 (es) Procedimiento de transferencia de datos y aparato que opera insertando otro contenido en el contenido principal
TW201145878A (en) Transmission method, reception method, transmission apparatus, and reception apparatus
KR20110053178A (ko) 적응적인 스트리밍 방법 및 장치
KR100819622B1 (ko) 정보 단말 장치 및 정보 단말 수신 방법, 디지털 방송 수신 장치 및 방법과 출력시간 계산 장치 및 방법
JP2005123907A (ja) データ再構成装置
CA2977708C (en) Broadcast system with a watermark payload
EP3240195B1 (en) Method and apparatus for decoding audio bitstream including system data
EP0980185B1 (en) Auxiliary data insertion in a transport datastream
AU2015200766B2 (en) Transport Stream Packet Header Compression
KR20110096549A (ko) Ｄｍｂ 표준에 따른 디지털 데이터 파일 전송방법 및 디바이스
BR112012029232B1 (pt) Provedor de fluxo de transporte, provedor de sinal dab, analisador de fluxo de transporte, receptor dab, método e sinal de fluxo de transporte
KR20140118059A (ko) 콘텐츠 재생 방법

Legal Events

Date Code Title Description
B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B25G Requested change of headquarter approved

Owner name: THOMSON LICENSING (FR)

B25A Requested transfer of rights approved

Owner name: THOMSON LICENSING DTV (FR)

B25A Requested transfer of rights approved

Owner name: INTERDIGITAL MADISON PATENT HOLDINGS (FR)

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B09Y Publication of grant cancelled [chapter 9.1.2 patent gazette]

Free format text: ANULADA A PUBLICACAO CODIGO 9.1 NA RPI NO 2544 DE 08/10/2019 POR TER SIDO INDEVIDA.

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 17/12/2019, OBSERVADAS AS CONDICOES LEGAIS.