BRPI0609561A2 - dispositivo e método para processar um fluxo de dados, meio legìvel por computador, e, elemento de programa para processar um fluxo de dados - Google Patents
dispositivo e método para processar um fluxo de dados, meio legìvel por computador, e, elemento de programa para processar um fluxo de dados Download PDFInfo
- Publication number
- BRPI0609561A2 BRPI0609561A2 BRPI0609561-5A BRPI0609561A BRPI0609561A2 BR PI0609561 A2 BRPI0609561 A2 BR PI0609561A2 BR PI0609561 A BRPI0609561 A BR PI0609561A BR PI0609561 A2 BRPI0609561 A2 BR PI0609561A2
- Authority
- BR
- Brazil
- Prior art keywords
- data stream
- truncation
- frame
- stream
- encrypted
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000012545 processing Methods 0.000 title claims abstract description 43
- 238000001514 detection method Methods 0.000 claims abstract description 25
- 230000008569 process Effects 0.000 claims abstract description 19
- 238000009826 distribution Methods 0.000 claims description 19
- 230000002441 reversible effect Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 7
- 230000002457 bidirectional effect Effects 0.000 claims description 6
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 abstract description 2
- 238000003860 storage Methods 0.000 description 38
- 239000002585 base Substances 0.000 description 35
- NUHSROFQTUXZQQ-UHFFFAOYSA-N isopentenyl diphosphate Chemical compound CC(=C)CCO[P@](O)(=O)OP(O)(O)=O NUHSROFQTUXZQQ-UHFFFAOYSA-N 0.000 description 12
- 238000004422 calculation algorithm Methods 0.000 description 11
- 239000000243 solution Substances 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 239000000203 mixture Substances 0.000 description 7
- 238000003752 polymerase chain reaction Methods 0.000 description 7
- 102100037812 Medium-wave-sensitive opsin 1 Human genes 0.000 description 6
- 230000006978 adaptation Effects 0.000 description 6
- 238000002474 experimental method Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 230000036961 partial effect Effects 0.000 description 6
- 230000006835 compression Effects 0.000 description 5
- 238000007906 compression Methods 0.000 description 5
- 238000009499 grossing Methods 0.000 description 5
- 238000003780 insertion Methods 0.000 description 5
- 230000037431 insertion Effects 0.000 description 5
- 238000010276 construction Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000004140 cleaning Methods 0.000 description 2
- 238000007405 data analysis Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 101100500563 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) ECM5 gene Proteins 0.000 description 1
- 101100019493 Schizosaccharomyces pombe (strain 972 / ATCC 24843) jmj3 gene Proteins 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 239000003637 basic solution Substances 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000428 dust Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012966 insertion method Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000013139 quantization Methods 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/91—Television signal processing therefor
- H04N5/913—Television signal processing therefor for scrambling ; for copy protection
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
-
- 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/26606—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing entitlement messages, e.g. Entitlement Control Message [ECM] or Entitlement Management Message [EMM]
-
- 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/44—Processing 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/44008—Processing 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 operations for analysing video streams, e.g. detecting features or characteristics in the video 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/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/44—Processing 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/4405—Processing 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 stream decryption
-
- 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
-
- 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
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
- H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Television Signal Processing For Recording (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Abstract
DISPOSITIVO E MéTODO PARA PROCESSAR UM FLUXO DE DADOS, MEIO LEGìVEL POR COMPUTADOR, E, ELEMENTO DE PROGRAMA PARA PROCESSAR UM FLUXO DE DADOS. Um dispositivo (3400) para processar um fluxo de dados criptografado (3401) onde o dispositivo (3400) compreende uma unidade de descriptografia (3402) para gerar um fluxo de dados descriptografado (3403) a partir do fluxo de dados criptografado (3401), uma unidade de detecção (3404) para detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografado (3403), e uma unidade de substituição (3405) para substituir, com base na informação de posição detectada, porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403).
Description
"DISPOSITIVO E MÉTODO PARA PROCESSAR UM FLUXO DE DADOS, MEIO LEGÍVEL POR COMPUTADOR, E, ELEMENTO DE PROGRAMA PARA PROCESSAR UM FLUXO DE DADOS"
CAMPO DA INVENÇÃO
A invenção relaciona-se a um dispositivo para processar um fluxo de dados criptografados.
Além disto, a invenção relaciona-se a um método para processar um fluxo de dados criptografados.
Ainda mais, a invenção relaciona-se a um dispositivo para processar um fluxo de dados possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes.
A invenção relaciona-se adicionalmente a um método para processar um fluxo de dados possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes.
Ainda mais, a invenção relaciona-se a um elemento de programa.
Adicionalmente, a invenção relaciona-se a um meio legível por computador.
FUNDAMENTOS DA INVENÇÃO
Dispositivos de entretenimento eletrônicos tornam-se mais e mais importantes. Particularmente, um número crescente de usuários adquire reprodutores de áudio/vídeo baseados em disco rígido e outros equipamentos de entretenimento.
Uma vez que a redução de espaço de armazenagem é um problema importante no campo de reprodutores de áudio/vídeo, dados de áudio e vídeo são freqüentemente armazenados de uma maneira comprimida, e por razões de segurança de uma maneira criptografada.
MPEG2 é um padrão para a codificação genérica de filmes e áudio associado e cria um fluxo de vídeo além dos dados de quadro, que pode ser arranjado em uma ordem específica chamada estrutura GOP ("Grupo De Imagens"). Um fluxo de bits de vídeo MPEG2 é composto de uma série de quadros de dados codificando imagens. As três maneiras de codificar uma imagem são intra-codificada (imagem I), preditiva direta (imagem P) e preditiva bidirecional (imagem B). Um quadro intra-codificado (quadro I) é relacionado a uma imagem particular e contém os dados correspondentes. Um quadro preditivo direto (quadro P) necessita informação de um quadro I ou quadro P precedente. Um quadro preditivo bidirecional (quadro B) é dependente de informação de um quadro I ou quadro P precedente ou subseqüente.
E uma função interessante em um dispositivo de reprodução de mídia prover, em adição a um modo de reprodução normal, no qual conteúdo de mídia é reproduzido em uma velocidade normal, um modo de reprodução rápido, no qual o conteúdo de mídia é reproduzido de uma maneira modificada, por exemplo, com uma velocidade aumentada.
Entretanto, para gerar um fluxo de truncagem pode ser necessário processar os dados de uma maneira complicada.
WO03/107664 Al descreve um método e um aparelho para processar um fluxo que contém uma informação criptografada, onde os inícios e términos de quadros I são detectados. Em resposta à detecção, é controlado se um pacote correspondente é criptografado.
OBJETIVO E SUMÁRIO DA INVENÇÃO
E um objetivo da invenção processar um fluxo de dados de uma maneira eficiente.
No sentido de alcançar o objetivo definido acima, um dispositivo e um método para processar um fluxo de dados criptografados, um dispositivo e um método para processar um fluxo de dados possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, um elemento de programa e u meio legível por computador de acordo com as reivindicações independentes, são providos.
De acordo com uma realização típica da invenção, um dispositivo para processar um fluxo de dados criptografados é provido, no qual o dispositivo compreende uma unidade de descriptografia para gerar um fluxo de dados descriptografados a partir do fluxo de dados criptografados, uma unidade de detecção para detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografados, e uma unidade de substituição para substituir, com base na informação de posição detectada porções do fluxo de dados criptografados por porções correspondentes do fluxo de dados descriptografados.
De acordo com uma outra realização típica da invenção, um método para processar um fluxo de dados criptografados é provido, onde o método compreende as etapas de gerar um fluxo de dados descriptografados a partir do fluxo de dados criptografados, detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografados, e substituir, com base na informação de posição detectada, porções do fluxo de dados criptografados por porções correspondentes do fluxo de dados descriptografados.
De acordo ainda com uma outra realização típica da invenção, um dispositivo para processar um fluxo de dados possuindo uma seqüência de pacote e informação de temporização relacionada aos pacotes, é provido, onde o dispositivo compreende uma unidade de distribuição para distribuir uniformemente os pacotes através do fluxo de dados, e uma unidade de substituição para substituir a informação de temporização do fluxo de dados, por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
De acordo com uma outra realização típica da invenção, o método para processar um fluxo de dados tendo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, é provido, no qual o método compreende as etapas de distribuir uniformemente os pacotes através do fluxo de dados, e substituir a informação de temporização do fluxo de dados por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
Além disto, de acordo com uma outra realização típica da invenção, um meio legível por computador é provido, no qual um programa de computador é armazenado, cujo programa de computador, ao ser executado por um processador, é adaptado para controlar ou executar algum dos métodos acima mencionados.
Ainda mais, de acordo ainda com uma outra realização típica da invenção, um elemento de programa é provido, cujo elemento de programa, ao ser executado por um processador, é adaptado para controlar ou realizar algum dos métodos acima mencionados.
O processamento de dados de acordo com a invenção pode ser realizado por um programa de computador, quer dizer, por software, ou usando um ou mais circuitos de otimização eletrônicos, quer dizer, em hardware, ou de forma híbrida, quer dizer por meio de componentes de software e componentes de hardware.
As características de acordo com a invenção possuem particularmente a vantagem de que o processamento de um fluxo de dados pode ser executado de uma maneira eficiente, substituindo seletivamente somente aqueles dados em um fluxo de dados que são requeridos para o uso adicional do fluxo de dados. Em outras palavras, um fluxo de dados existente é modificado apenas parcialmente (e preferivelmente tão poucas modificações quanto possível são executadas. De tal modo que o fluxo de dados resultante pode ser usado como uma base para uma aplicação alvo particular, por exemplo, geração de truncagem. Então, um aspecto comum das realizações da invenção é direcionado à substituição seletiva de porções particulares de um fluxo de dados. De acordo com aspecto da invenção, isto é particularmente realizado descriptografando um fluxo de dados criptografados completamente, detectando posições de quadro I no fluxo de dados plenamente descriptografados e substituindo seletivamente apenas aquelas porções no fluxo de dados criptografados que se relacionam a posições dos quadros I. Adotando esta medida, pode ser assegurado que somente aquelas porções para as quais a transmissão não criptografada é absolutamente necessária permaneçam descriptografadas - particularmente para permitir que o fluxo de dados processados sendo uma mistura de partes criptografadas e descriptografadas seja usado como base para geração de truncagem. Então, um processamento eficiente e um alto nível de segurança podem ser obtidos simultaneamente.
Portanto, no caso de um fluxo de reprodução normal original criptografado (particularmente em um padrão MPEG) um fluxo de truncagem criptografado de radiodifusão de vídeo digital (DVB) pode ser gerado, mesmo em um cenário no qual o uso de uma máquina de criptografia DVB (por exemplo, em casa) não é permitido.
De acordo com uma realização típica deste aspecto da invenção, um método para gerar um fluxo híbrido a partir de um fluxo de transporte de vídeo criptografado consistindo de pacotes de dados é provido, onde primeiramente um fluxo de transporte descriptografado do fluxo de transporte de vídeo criptografado é gerado. Então, quadros I podem ser detectados no fluxo de transporte descriptografado, onde apontadores para o início e término do(s) quadro(s) I podem ser identificados. Adicionalmente, nas posições dos indicadores para o início e para o fim dos quadros I, pacotes descriptografados correspondentes do fluxo de transporte descriptografado podem substituir os pacotes criptografados no fluxo de transporte.
Então, um fluxo de transporte híbrido (quer dizer, basicamente um fluxo de transporte criptografado com alguns pacotes em texto simples) pode ser gerado. Neste contexto, os pacotes do fluxo de transporte que deveriam ser no mínimo em texto simples (para serem capazes de gerar um fluxo de transporte de truncagem MPEG2 válido a partir deste fluxo híbrido) podem ser gerados ou selecionados. Adicionalmente, a detecção de vários campos importantes necessários para construir um fluxo de transporte de truncagem pode ser realizado. Portanto, um fluxo de truncagem criptografado (DVB) pode ser gerado mesmo se o uso de uma máquina de criptografia (DVB) doméstica não é permitida. Campos de aplicação típicos do sistema de acordo com a invenção, são dispositivos de gravação de vídeo digitais (tais como combinações HDD, DVD+RW, etc.) e dispositivos habilitados pela rede usando truncagem.
De acordo com um aspecto descrito da invenção, uma quantidade mínima de dados que deveria ser em texto simples de qualquer quadro (quadro I, quadro P ou quadro B) pode ser estimada para permitir a geração de um fluxo de truncagem criptografado a partir dele. Além disso, é possível decidir quais pacotes de fluxo de transporte deveriam ser em texto simples, e quais deveria permanecer criptografados. Esta decisão e correspondente conversão (particularmente descriptografia) é destinada a ser feita na extremidade de radiodifusão ou no dispositivo de armazenagem recebendo o fluxo.
Ainda mais, é possível, de acordo com a invenção, detectar os limites do quadro neste fluxo criptografado parcialmente (mas freqüentemente quase completamente) novamente na extremidade do receptor, quando um fluxo de truncagem deve ser gerado a partir deste fluxo. Isto permite criar um fluxo de truncagem criptografado. Portanto, um fluxo de transporte criptografado pode ser criado, e para esta finalidade posições de quadro podem ser detectadas.
De acordo com o aspecto descrito da invenção, é possível começar com um fluxo criptografado, e somente podem ser descriptografados aqueles pacotes que necessitam ser mudados. Estes não são usualmente re- criptografados, particularmente em um cenário no qual um criptografador não pode ser usado. Para executar esta ação, o fluxo pode ser primeiramente descriptografado no sentido de encontrar cabeçalhos. De fato, o aspecto descrito pode usar um texto simples e um fluxo criptografado como entradas. Com base na detecção de cabeçalho, pode ser feita uma seleção cujo fluxo de entrada é passado para a saída. A totalidade do processamento pode ser executada dentro de um ambiente seguro com tempos de um IC, de tal modo que o fluxo de texto simples pode não ser acessível. Isto significa que o sistema pode ter um fluxo de entrada criptografado e um fluxo de saída principalmente criptografado com alguns pacotes de texto simples. Em alguns casos, nem todos os pacotes contendo informação de cabeçalho podem estar em texto simples, porque somente aquelas porções que serão mudadas necessitam estar em texto simples, e não necessariamente o cabeçalho completo. Isto é especialmente claro quando, por exemplo, o código de início de imagem é dividido entre dois pacotes. Neste caso, parte do código de início de imagem pode ainda ser criptografado. Um algoritmo pode ser provido para selecionar os pacotes que necessitam estar em texto simples. Este algoritmo pode conduzir a códigos de início de imagem parcialmente criptografados, porém pode minimizar a demanda de memória. Colocar o código de início de imagem completo em texto simples conduziria à necessidade de um meio de armazenagem temporária de memória maior.
De acordo com um outro aspecto da invenção, um fluxo de dados tendo uma seqüência de pacotes e informação de temporização relacionada a estes pacotes pode ser processado distribuindo suavemente ou uniformemente pacotes do fluxo de dados, e substituindo e atualizando informação de temporização do fluxo de dados, gerando e incorporando informação de temporização relacionada ao fluxo de dados suavizado. Entretanto, a substituição pode ser efetuada antes da distribuição. Por esta substituição de partes do fluxo de dados para conformidade de um fluxo de dados suavizado com exigências de informação de temporização correspondentes, é gerado um fluxo de dados modificado que pode servir como parte da geração de truncagem.
De acordo com este aspecto da invenção, é provido um método para gerar um fluxo de truncagem a partir de um fluxo de vídeo, no qual o fluxo de vídeo pode ser composto de um Grupo De Imagens (GOP) organizado em pacotes, os pacotes são transmitidos dentro de uma janela de tempo GOP. De acordo com o método descrito, pacotes de Referência de Relógio de Programa (PCR) podem ser calculados com base em uma distância de tempo de pacote além de um número total de pacotes de um GOP e da janela de tempo GOP. Ainda mais, adicionar pacotes de Referência de Relógio de Programa (PCR) no início de cada GOP de truncagem pode gerar uma base de tempo para o fluxo de truncagem.
Se presente, uma Marcação de Tempo de Decodificação (DTS) e/ou uma Marcação de Tempo de Apresentação (PTS) pode ser adaptada correspondentemente com uma base de tempo.
Em um caso típico de um fluxo de truncagem criptografado, Mensagens de Controle de Intitulação (ECM) podem estar presentes neste fluxo de truncagem para habilitar a descriptografla por um receptor (por exemplo, um "conversor de caixa de topo", STB). Por exemplo, uma ECM pode ser adicionada ao final de um GOP de truncagem prévio do fluxo de truncagem.
De acordo com o aspecto descrito da invenção, um fluxo de truncagem (criptografado ou em texto simples, ou sendo uma mistura de ambos) no nível de fluxo de transporte pode ser processado pelos mesmos circuitos de saída usados para reprodução normal (particularmente sem fazer qualquer re-multiplexação). Ainda mais, baixos recursos de processamento podem ser suficientes para construir a truncagem no nível de fluxo de transporte. Ainda mais, um método de truncagem de acordo com uma realização típica da invenção pode ser usado para fluxos de transporte com ou sem marcações de tempo de chegada e de pacote pré-pendentes.
Então, de acordo com uma realização típica da presente invenção, a construção de fluxo de truncagem no nível de fluxo de transporte é habilitada sem re-multiplexação. Para esta finalidade, um fluxo de truncagem pode ser gerado além de um fluxo de transporte, onde os pacotes são suavizados através de um GOP de fluxo de truncagem, a informação de temporização pode ser substituída por uma nova informação de base de tempo (por exemplo, PTS, DTS, PCR e Mensagens de Controle de Intitulação (ECM) podem ser adicionadas ao fluxo de truncagem criptografado (por exemplo, no final do GOP de truncagem).
A seguir, alguns aspectos adicionais de acordo com uma realização típica da invenção serão descritos.
Pacotes de fluxo de transporte podem ser suavizados através de um GOP de truncagem ("TP GOP"). Adicionalmente, uma distância em um tempo de transmissão entre os TP GOP pode ser constante e exatamente igual ao tempo de visualização total dos quadros e do GOP. Um pacote PCR adicional pode ser provido no início de cada GOP. O tamanho do pacote PES pode ser igual a um TP GOP, o que resulta em um DTS/PTS por TP GOP. Além disso, o DTS pode ser igual ou maior do que o PCR base do próximo TP GOP. Por exemplo, pode ser igual ao PCR base do próximo TP GOP. O PCR base do próximo TP GOP pode ser igual ao PCR base do TP GOP corrente mais um valor delta constante. Além disso, pode ser exatamente definido qual ECM deveria ser inserido em que ponto do fluxo, para melhorar ou otimizar o desempenho. Dependendo de uma alavanca SCB (Bits de Controle de Mistura) esta posição pode estar nos limites TP GOP e algumas vezes dentro dos dados de quadro I.
A seleção das distância no tempo de transmissão entre os TP GOP para ser constante e igual ao tempo de visualização total dos quadros no GOP, e a provisão de um pacote PCR adicional no início de cada TP GOP pode conduzir a um mecanismo simples para a geração dos PCR, porque a extensão PCR pode ser ajustada para zero, omitindo a necessidade de um cálculo módulo 300 mais completo. Ainda mais, a diferença entre os PCR subseqüentes pode ser um valor delta fixo, cujo valor delta pode contribuir adicionalmente para a simplificação do algoritmo.
Provendo o tamanho do pacote PES igual a um TP GOP, e provendo o DTS para ser igual ou maior do que a base PCR de um próximo TP GOP, um algoritmo simples é obtido para a geração dos valores DTS, porque o mesmo delta fixo pode ser usado como para os PCR. De fato, o DTS pode ser igual ao PCR que tem que ser inserido no próximo TP GOP. Em outras palavras, o PCR pode ser igual ao DTS do TP GOP prévio. Isto significa que o cálculo, de fato, somente tem que ser efetuado uma vez ao invés de duas.
A inserção de um ECM permite otimizar a estrutura do fluxo de dados modificado.
Adicionalmente pode ser vantajoso construir um fluxo de truncagem criptografado a partir de um fluxo de reprodução normal criptografado. Isto pode ser particularmente vantajoso para avanço rápido ou reverso, mas ainda mais para avanço lento. Ainda mais, pode ser vantajoso que o método de criptografia para o fluxo de truncagem seja idêntico ao da reprodução normal.
Referindo-se às reivindicações dependentes, realizações típicas adicionais da invenção serão descritas.
A seguir, realizações típicas do dispositivo para processar um fluxo de dados criptografados serão descritas. Estas realizações podem também ser aplicadas para o método de processamento de um fluxo de dados criptografados, para o meio legível por computador e para o elemento de programa.
A unidade de detecção pode ser adaptada para detectar informação de posição de pelo menos um quadro preditivo de avanço (quadro P) e/ou pelo menos um quadro preditivo bidirecional (quadro B) no fluxo de dados descriptografados. Em outras palavras, em adição ou como uma alternativa à detecção de limites de quadro I e para a substituição de porções criptografadas correspondentes do fluxo de dados por porções descriptografadas, também limites de quadro P e/ou quadro B podem ser detectados ou substituídos por porções descriptografadas correspondentes. Para diversas aplicações de truncagem, pode ser vantajoso encontrar todos os limites de quadros.
O dispositivo pode ser adicionalmente adaptado para gravar um sistema híbrido. Um fluxo híbrido compreendendo porções criptografadas originais e porções descriptografadas modificadas, pode ser armazenado no dispositivo.
A unidade de detecção do dispositivo pode ser adaptada para detectar, como informação de posição, uma posição de partida e uma posição final de pelo menos um quadro intra-codificado no fluxo de dados descriptografados. Somente a posição de partida e a posição final de um quadro I tem que ser inserida de uma maneira decodificada, independente disto, no fluxo de dados criptografados. Tomando esta medida, a quantidade de dados descriptografados no fluxo de dados pode ser minimizada de tal modo que a segurança pode ser maximizada.
A unidade de substituição pode ser adaptada para substituir porções do fluxo de dados criptografados por porções correspondentes do fluxo de dados descriptografados na posição de partida detectada e posição final de pelo menos um quadro intra-codificado no fluxo de dados descriptografados. Particularmente, a parte principal dos quadros I pode permanecer criptografada, o que permite um alto grau de segurança. Ainda mais, uma unidade de adição pode ser provida, adaptada para adicionar informação de temporização a um fluxo de dados que já tenha sido processado antes pela unidade de substituição. Uma vez que a informação de temporização antiga relaciona-se ao fluxo de dados original, a transição para truncagem pode ter a conseqüência de que a informação de temporização pode não ser mais correta para truncagem. Para esta finalidade, a informação de temporização pode ser atualizada de acordo com o fluxo de dados modificado.
Particularmente, a unidade de adição pode ser adaptada para adicionar a informação de temporização em texto simples. Então, somente a informação de temporização e os inícios e fins dos quadros I podem estar em texto simples, onde o restante do fluxo de dados pode permanecer criptografado. A unidade de substituição pode ser adaptada adicionalmente para substituir a quantidade de dados do fluxo de dados criptografados por porções correspondentes do fluxo de dados descriptografados, cuja quantidade é minimamente requerida para gerar um fluxo de dados para reprodução em um modo de reprodução de truncagem. Minimizando a quantidade de conteúdo de dados descriptografados, independente disto, no fluxo de dados criptografados, o perigo de um acesso não autorizado aos dados é minimizado.
A unidade de substituição pode ser adaptada de tal maneira que os dados entrem numa posição de partida e numa posição final de pelo menos um quadro intra-codificado, podem estar livres de serem substituídos por porções correspondentes do fluxo de dados descriptografados. A descriptografia somente no começo e fim de um quadro I permite manter a maioria de um bloco de dados de quadro I criptografada e somente porções necessárias são descriptografadas e transmissíveis em texto simples. A unidade de adição pode ser localizada em uma unidade de geração de truncagem, ao passo que a unidade de substituição pode ser localizada em uma unidade de geração de truncagem, ao passo que a unidade de reprodução pode ser localizada em um lado de gravação. A unidade de substituição pode ser adicionalmente adaptada para substituir um indicador de extensão de pacote PES5 uma Marcação de Tempo de Apresentação (PTS) e/ou uma Marcação de Tempo de Decodificação (DTS) em uma unidade de cabeçalho do fluxo de dados parcialmente criptografado.
O dispositivo de acordo com a invenção pode ser adaptado para processar um fluxo de dados criptografados de dados de vídeo ou dados de áudio. Entretanto, tal conteúdo de mídia não é o único tipo de dados que podem ser processados com o esquema de acordo com a invenção. A geração de truncagem e aplicações similares são um problema para ambos processamento de vídeo e processamento de áudio (puro).
O dispositivo de acordo com a invenção pode ser adaptado para processar um fluxo de dados criptografados de dados digitais.
Ainda mais, o dispositivo pode compreender uma unidade de geração de truncagem adaptada para gerar um fluxo de dados para reprodução em um modo de reprodução de truncagem, com base em uma saída da unidade de reprodução. Um usuário pode ajustar tal modo de truncagem selecionando opções correspondentes em uma interface de usuário, por exemplo, teclas de um dispositivo, um teclado alfanumérico ou um controle remoto. O modo de reprodução de truncagem selecionado por um usuário que pode requerer a informação concernente à posição dos quadros I pode ser uma do grupo consistindo de um modo de reprodução de avanço rápido, um modo de reprodução de avanço reverso, um modo de reprodução de movimento lento, um modo de reprodução de quadro congelado, um modo de reprodução de reprodução instantânea, e um modo de reprodução reverso. Outros esquemas de truncagem são entretanto, possíveis. Para truncagem, apenas uma porção dos dados subseqüente serão usados para saída, por exemplo, para exibição visual e/ou para saída acústica. Uma vez que nem todos os dados (quadros Ρ, quadros Β) em um fluxo de dados, podem ser usados independentemente a partir de outros dados (quadros I) para gerar sinais visualizáveis, o conhecimento dos dados utilizáveis independentemente (quadros I) pode ser desejado.
O dispositivo de acordo com a invenção pode ser adaptado para processar um fluxo de dados MPEG2 criptografado. MPEG2 é uma designação para um grupo de padrões de codificação de vídeo acordado pelo MPEG (Grupo de Especialistas Cinematográficos) e publicado como o padrão internacional ISO/IEC 13818. MPEG2 pode ser usado para codificar áudio e vídeo para sinais de radiodifusão incluindo seletor de almofada de toque digital e TV a cabo, mas é também usado para DVD.
O dispositivo de acordo com a invenção pode ser realizado como pelo menos um do gravação consistindo de um dispositivo de gravação digital de vídeo, um dispositivo habilitado pela rede, um sistema de acesso condicional, um reprodutor de áudio portátil, um reprodutor de vídeo portátil, um telefone móvel, um reprodutor de DVD, um reprodutor de CD, um reprodutor de mídia baseado em disco rígido, um dispositivo rádio Internet, um dispositivo de entretenimento publico e um reprodutor de mp3. Entretanto, estas aplicações são apenas típicas.
A seguir, realizações típicas do dispositivo para processar um fluxo de dados possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, será descrita. Estas realizações podem também ser aplicadas para o método de processar um fluxo de dados tendo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, para o meio legível por computador e elementos de programa.
Neste dispositivo, a unidade de distribuição pode ser adaptada para distribuir uniformemente pacotes relacionados a uma porção do fluxo de dados entre dois quadros intra-codificados subseqüentes. Em uma unidade de radiodifusão, diferentes pacotes relacionados a um quadro I podem ser providos de uma maneira não eqüidistante. A unidade de distribuição pode rearranjar os pacotes equidistantemente, quer dizer, suavizar a distribuição dos pacotes no domínio do tempo. A suavização pode ser efetuada independentemente para cada grupo de pacotes relacionado a um quadro I particular. Tomando esta medida, é possível manter a taxa de bit local tão pequena quanto possível onde a taxa média permanece a mesma.
A unidade de substituição pode ser adaptada para arranjar a informação de temporização modificada em uma posição inicial do fluxo de dados processado. Então, a informação de temporização precede os pacotes, e uma posição vantajosa para prover tal informação de temporização é obtida.
A unidade de substituição pode ser adicionalmente adaptada para gerar uma Referência de Relógio de Programa, uma Marcação de Tempo de Decodificação e/ou uma Marcação de Tempo de Apresentação como a informação de temporização modificada. Uma Marcação de Tempo de Decodificação/Marcação de Tempo de Apresentação depende de uma Referência de Relógio de Programa.
Particularmente, o dispositivo pode ser adaptado para processar um fluxo de dados criptografados, e pode compreender uma unidade de inserção de informação de descriptografia adaptada para inserir informação de descriptografia no fluxo de dados processados, para descriptografar o fluxo de dados criptografados. Por exemplo, Mensagens de Controle de Intitulação (ECM) podem ser inseridas na informação de descriptografia pela unidade de inserção de informação de descriptografia. Particularmente, pode ser vantajoso inserir a informação de descriptografia em uma extremidade do fluxo de dados processados. Mais particularmente, pode ser possível que a informação de temporização seja pré fixada aos dados reais, e que as ECM sejam providas no final dos dados, de tal modo que os dados são "sanduichados" pela informação de temporização e informação de descriptografia. Conforme já mencionado acima o dispositivo pode ser adaptado para processar um fluxo de dados de dados de vídeo ou dados de áudio. Particularmente, dados visuais puros, dados audíveis puros ou uma mistura ou combinação de ambos podem ser processados de acordo com a invenção.
O dispositivo pode ser adaptado para processar um fluxo de dados de dados digitais. Conforme mencionado acima, geração de truncagem pode ser possível. Diferentes modos de reprodução típicos para truncagem são mencionados acima.
Conforme mencionado adicionalmente acima, é possível processar um fluxo de dados MPEG2 criptografado. Adicionalmente, têm sido descritos dispositivos acima, nos quais o dispositivo da invenção pode ser vantajosamente integrado.
Os aspectos referidos acima e aspectos adicionais da invenção são aparentes a partir dos exemplos de realização a serem descritos posteriormente são explicados com referência a estes exemplos de realização. BREVE DESCRIÇÃO DOS DESENHOS
A invenção será descrita em mais detalhe posteriormente, com referência a exemplos de realização, ao qual, porém, a invenção não está limitada.
Figura 1 ilustra um pacote de fluxo de transporte com marcação de tempo.
Figura 2 mostra um grupo MPEG2 de estrutura de imagem com quadros intra-codificados e quadros preditivos de avanço.
Figura 3 ilustra um grupo MPEG2 de estrutura de imagem com quadros intra-codificados, quadros preditivos de avanço e quadros preditivos bidirecionais.
Figura 4 ilustra uma estrutura de um arquivo de informação de ponto característico e conteúdo de fluxo armazenado. Figura 5 ilustra um sistema para truncagem em um fluxo de texto simples.
Figura 6 ilustra compressão de tempo na truncagem.
Figura 7 ilustra truncagem por distância fracionária.
Figura 8 ilustra truncagem de baixa velocidade.
Figura 9 ilustra uma estrutura de sistema de acesso condicional geral.
Figura 10 ilustra um pacote de fluxo de transporte criptografado de radiodifusão de vídeo digital.
Figura 11 ilustra um cabeçalho de pacote de fluxo de transporte do pacote de fluxo de transporte criptografado de radiodifusão de vídeo digital da Figura 10.
Figura 12 ilustra um sistema permitindo executar truncagem sobre um fluxo plenamente criptografado.
Figura 13 ilustra um fluxo de transporte pleno e um fluxo de transporte parcial.
Figura 14 ilustra um sistema de transmissão de dados entre um radiodifusor e um dispositivo de armazenagem para conversão de fluxo.
Figura 15 ilustra truncagem em uma gravação de texto simples.
Figura 16 ilustra truncagem em uma gravação plenamente criptografada.
Figura 17 ilustra truncagem em uma gravação parcialmente criptografada.
Figura 18 ilustra uma demanda de meio de armazenagem temporária para código de início de imagem completamente de texto simples.
Figura 19 ilustra uma área de texto simples prática no início de um quadro I.
Figura 20A e Figura 20B ilustram áreas de texto simples práticas.
Figura 21 ilustra códigos de início de imagem espalhados por dois pacotes.
Figura 22 ilustra quadro P vazio anexado a código de início de imagem parcialmente criptografado;
Figura 23 ilustra áreas de dados de texto simples.
Figura 24 ilustra uma estrutura de cabeçalho no padrão MPEG2.
Figura 25 ilustra código de extensão de seqüência e cabeçalho de seqüência.
Figura 26 ilustra código de extensão de codificação de imagem e início de imagem.
Figura 27 ilustra código de cabeçalho de seqüência espalhado através de dois pacotes.
Figura 28 ilustra suavização de pacote em truncagem. Figura 29 ilustra DTS e PTS em relação a uma base de tempo PCR.
Figura 30 ilustra a inserção das ECM entre os GOP de truncagem.
Figura 31 ilustra a inserção das ECM em um quadro I. Figura 32 ilustra um caminho de sinal entre um dispositivo de radiodifusão e de armazenagem e localizações para conversão para o fluxo híbrido.
Figura 33 ilustra a geração de truncagem seguro a partir de uma gravação plenamente criptografada.
Figura 34A ilustra um diagrama em blocos de geração de sistema híbrido de um dispositivo para processar um fluxo de dados criptografados de acordo com a realização típica da invenção.
Figura 34B ilustra um diagrama em blocos de geração de fluxo de truncagem, que pode ser usado juntamente com o diagrama em blocos de geração de fluxo híbrido da Figura 34A, do dispositivo para processar um fluxo de dados criptografados de acordo com a realização típica da invenção.
Figura 35 ilustra pacotes de dados em diferentes estágios de um método para processar um fluxo de dados criptografados de acordo com a realização típica da invenção.
Figura 36 ilustra um dispositivo para processar um fluxo de dados tendo uma seqüência de pacotes e informação de temporização relacionados aos pacotes de acordo com uma realização típica da invenção.
DESCRIÇÃO DAS REALIZAÇÕES
A ilustração no desenho é esquemática. Em diferentes desenhos, elementos similares ou idênticos são providos dos mesmos sinais de referência.
A seguir, referindo-se à Figura 1 à Figura 13, serão descritos diferentes aspectos de implementação de truncagem para fluxos de transporte de acordo com realizações típicas da invenção.
Particularmente, várias possibilidades de executar truncagem em um fluxo codificado do MPEG2, serão descritas, que podem ser parcialmente ou totalmente criptografadas ou não criptografadas. A seguinte descrição objetivará métodos específicos para o formato de fluxo de transporte MPEG2. Entretanto, a invenção não está restrita a este formato.
Experiências foram realmente feitas com uma extensão, o assim chamado fluxo de transporte com marcação de tempo. Este compreende pacotes de fluxo de transporte, todos os quais são pré pendentes com um cabeçalho de 4 bytes no qual o tempo de chegada do pacote de fluxo de transporte é colocado. Este tempo pode ser derivado do valor da base de tempo de referência de relógio de programa (PCR) no instante do primeiro byte do pacote ser recebido no dispositivo de gravação. Este é um método adequado para armazenar a informação de temporização com o fluxo, de tal modo que a reprodução do fluxo se torna um processo relativamente fácil.
Um problema durante a reprodução é assegurar que o meio de armazenagem temporária do decodificador MPEG2 não apresentará extravasamento nem retenção. Se o fluxo de entrada for conforme ao modelo de meio de armazenagem temporária de decodificador, restaurar a temporização relativa assegura que o fluxo de transporte é também conforme. Alguns dos métodos de truncagem aqui descritos são independentes da marcação de tempo e funcionam igualmente bem com fluxos de transporte com ou sem marcações de tempo.
Figura 1 ilustra um pacote de fluxo de transporte com marcação de tempo 100 possuindo uma extensão total 104 de 188 bytes e compreendendo uma marcação de temo 101 possuindo uma extensão 105 de 4 bytes, um cabeçalho de pacote 102 e uma carga útil de pacote 103 possuindo uma extensão de 184 bytes.
Esta descrição a seguir dará uma visão geral das possibilidades para criar um fluxo de truncagem conforme ao MPEG/DVB (radiodifusão de vídeo digital) a partir de um fluxo de transporte gravado e pretende cobrir o espectro total de fluxos gravados a partir daqueles que são completamente de texto simples, e assim todo bit de dados pode ser manipulado, para fluxos que são completamente criptografados (por exemplo, de acordo com o esquema DVB), de tal modo que apenas cabeçalhos e algumas tabelas podem ser acessíveis para manipulação. A invenção também equaciona uma solução entre estes extremos, onde apenas os dados que necessitam ser manipulados para gerar o fluxo de truncagem estão em texto simples.
Ao criar truncagem para um fluxo de transporte MPEG/DVB, podem surgir problemas quando o conteúdo é pelo menos parcialmente criptografado. Pode não ser possível descer ao nível de fluxo elementar, o que é a abordagem usual, ou mesmo acessar alguns cabeçalhos de fluxo elementar empacotados (PES) antes da descriptografia. Isto também significa que não é possível encontrar quadros de imagens. Máquinas de truncagem conhecidas necessitam ser capazes de acessar e processar esta informação.
No quadro desta descrição, o termo "ECM" denota uma Mensagem de Controle de Intitulação. Esta mensagem pode compreender particularmente informação proprietária secreta do provedor e pode, entre outras, conter palavras de controle criptografadas (CW) necessárias para descriptografar o fluxo MPEG. Tipicamente, palavras de controle expiram em 10-20 segundos. As ECM são embutidas em pacotes no fluxo de transporte.
No quadro desta descrição, o termo "códigos" denota particularmente dados que podem ser armazenados em um cartão inteligente e podem ser transferidos para o cartão inteligente, usando as EMM, que são assim chamadas "Mensagens de Gerenciamento de Intitulação" que podem ser embutidas no fluxo de transporte. Estes códigos podem ser usados pelo cartão inteligente para descriptografar as palavras de controle presentes na ECM. Um período de validade típico de tal código é de um mês.
No quadro desta descrição, o termo "palavras de controle" (CW) particularmente denota informação de descriptografia necessária para descriptografar o conteúdo real. Palavras de controle podem ser descriptografadas pelo cartão inteligente e então armazenadas em uma memória do núcleo de descriptografia.
A seguir, alguns aspectos relacionados a fluxos de truncagem em texto simples, serão descritos.
Mesmo se um fluxo MPEG2 não está criptografado (quer dizer em texto simples) a truncagem não é trivial. Uma solução fácil é apenas emitir os dados mais rapidamente para um decodificador, para obter um modo de avanço rápido, porém como MPEG possui informação relacionada a temporização codificada em seus cabeçalhos, isto não pode somente ser feito com as expectativa de obter um avanço rápido adequado. Além disso, pode ser difícil decidir quais quadros eliminar, pois este método para executar avanço rápido pode acarretar uma taxa de quadro mais alta que a taxa de visualização.
Ainda mais, tal fluxo não é um fluxo de transporte conforme ao MPEG2. Isto pode ser aceitável se o decodificador estiver no dispositivo de armazenagem, mas pode ser problemático se o sinal é transferido por uma interface digital padrão. Ainda mais, a taxa de bit pode aumentar dramaticamente em toda a cadeia. Se o fluxo de reprodução normal é um fluxo de transporte com marcação de tempo de um único programa originado de radiodifusão via satélite, a taxa de bit para o decodificador em reprodução normal pode ser em torno de 40 Mbps e pacotes podem estar em posições irregulares com espaços entre eles (fluxo de transporte parcial). Se o fluxo é comprimido com o fator de truncagem, a taxa de bit pode ser em torno de 120 Mbps para uma velocidade de truncagem de três vezes. A largura de faixa mantida necessária de um controlador de disco rígido pode também ser aumentada do fator de truncagem.
Assim, seria apropriado manter o envio da quantidade correta de quadro, mas aqui poderia ocorrer um problema ao usar uma técnica de codificação de vídeo como MPEG, que explora a redundância temporal de vídeo para obter altas taxas de compressão. Quadros não podem mais ser decodificados independentemente.
Uma estrutura de diversos grupos de imagem (GOP) é mostrada na Figura 2.
Particularmente, a Figura 2 mostra um fluxo 200 compreendendo várias estruturas MPEG2 GOP com uma seqüência de quadros I 201 e quadros P 202. O tamanho do GOP é denotado pelo numerai de referência 203. O tamanho do GOP 203 é ajustado para 12 quadros, e somente os quadros I 201 e quadros P 202 são mostrados aqui.
No MPEG, uma estrutura de GOP pode ser usada, na qual somente o primeiro quadro é codificado independentemente de outros quadros. Este é o assim chamado intra-codificado ou quadro I 201. Os quadros preditivos ou quadros P 202 são codificados com uma predição unidirecional, significando que estes apenas se apoiam no quadro I 201 prévio ou quadro P 202, conforme indicado pelas setas 204 na Figura 2.
Tal estrutura GOP tem tipicamente um tamanho de 12 ou 16 quadros 201, 202. É suposto que uma velocidade de truncagem de 2χ adiante é desejada. Assim, por exemplo, cada segundo quadro deveria ser pulado. Isto não é possível no domínio comprimido devido à dependência do quadro prévio reconstruído durante a decodificação. Assim, apenas eliminar alguns quadros comprimidos e corrigir a informação de temporização não é opção.
A alternativa é decodificar o fluxo inteiro primeiramente, então pular cada segundo quadro e finalmente codificar os quadros restantes novamente. Isto pode conduzir a uma complexidade inaceitável dos circuitos ou software de truncagem. Assim, no melhor caso, alguns quadros podem ser pulados do GOP, nos quais outros quadros não se apoiam. Para o exemplo de uma velocidade de truncagem de 2x com um tamanho do GOP de 12 quadros, somente os últimos 6 quadros P podem ser pulados. Neste caso, as imagens exibidas tendem a ser de natureza "pulada", onde um período de velocidade normal curto é obtida, seguido por um salto brusco no tempo. Especialmente em velocidades de truncagem mais altas isto pode ser desagradável e não dar ao espectador a visão e sensação de truncagem usual.
Uma outra estrutura 300 de diversos grupos de imagens (GOP) é mostrada na Figura 3.
Particularmente, Figura 3 mostra a estrutura MPEG2 GOP com uma seqüência de quadros I 201, quadros P 202 e quadros B 301. O tamanho do GOP é novamente denotado pelo numerai de referência 203.
E possível usar uma estrutura GOP contendo também quadros bidirecionalmente preditivos o quadros B 301, conforme mostrado na Figura 3. Um tamanho de GOP 203 de 12 quadros é escolhido para o exemplo. Os quadros B 301 são codificados com uma predição bidirecional, significando que estes se apoiam em um quadro I ou P próximo e seguinte, 201, 202, conforme indicado para alguns quadros B 301 pelas setas curvas 204. A ordem de transmissão dos quadros comprimidos pode não ser a mesma ordem na qual são exibidos.
Para decodificar um quadro B 301, ambos quadros de referência antes e depois do quadro B 301 (na ordem de visualização) são necessários. Para minimizar a demanda de meio de armazenagem temporária em um decodificador, os quadros comprimidos podem ser reordenados. Assim, na transmissão, os quadros de referência podem vir primeiro. O fluxo reordenado, como é transmitido, é também mostrado na Figura 3, parte inferior. A reordenação é indicada pelas setas retas 302. Um fluxo contendo quadros B 301 pode prover uma imagem de truncagem de bonito visual, se todos os quadros B 301 são pulados. Para o presente exemplo, isto conduz a uma velocidade de truncagem de 3x de avanço.
Qualquer que seja a estrutura do fluxo, as soluções descritas até agora podem produzir uma forma aceitável de truncagem para um modo de avanço rápido. Para reverso, os quadros teriam que ser reordenados no tempo, mas devido ao fato de que MPEG usa a correlação temporal entre quadros sucessivos para alcançar uma alta taxa de compressão, a ordem na qual os quadros tem que ser decodificados é fixa. Portanto, um GOP tem primeiramente que ser decodificado na direção direta. A ordem dos GOP enviados ao decodificador pode ser revertida, e os GOP podem ser pulados para velocidades de truncagem reversas mais altas. Reduzir os GOP pulando os quadros P ou quadros B conforme descrito acima é também possível neste caso. De qualquer modo, pode resultar em uma seqüência exibida de reprodução adiante e saltos para trás. Portanto, os quadros de truncagem tem que ser selecionados do GOP selecionado e de ordem reversa, após o que os quadros são re-codificados. Então, o GOP prévio é extraído e processado e assim por diante. Embora possível, a complexidade de tal procedimento pode ser alta.
Uma conclusão a partir das considerações precedentes é que usar somente os quadros I na geração da truncagem pode ser uma solução adequada, porque estes quadros podem ser decodificados independentemente. Como resultado, a geração de truncagem pode ser mais fácil, especialmente para reverso. Adicionalmente, o uso somente de quadros I já permite velocidades de truncagem baixas até 3x ou 4x. Para velocidades de truncagem realmente baixas, as técnicas mais complexas mencionadas acima podem ser implementadas.
A seguir, alguns aspectos relacionados a um arquivo de CPI ("informação de ponto característico") serão descritos.
Encontrar quadros I em um fluxo, usualmente requer analisar o fluxo, para encontrar os cabeçalhos do quadro. Localizar as posições onde o quadro I começa pode ser feito enquanto a gravação está sendo feita, ou off- line após a gravação ser completada, ou semi on-line, sendo de fato off-line porém com um pequeno retardo com respeito ao momento da gravação. O término do quadro I pode ser encontrado detectando o início do próximo quadro P ou quadro B. Os metadados derivados deste modo podem ser armazenados em um arquivo separado porém acoplado, que pode ser denotado como arquivo de informação de ponto característico ou arquivo CPI. Este arquivo pode conter apontadores para o início e eventualmente fim de cada quadro I no arquivo de fluxo de transporte. Cada gravação individual pode ter seu próprio arquivo CPI.
A estrutura de um arquivo de informação de ponto característico 400 é visualizada na Figura 4.
Além do arquivo CPI 400, informação armazenada 401 é mostrada. O arquivo CPI 400 pode também conter alguns outros dados que não são discutidos aqui. Com os dados a partir do arquivo CPI 400, é possível pular para o início de qualquer quadro I 201 no fluxo. Se o arquivo CPI 400 também contém o final dos quadros I 201, a quantidade de dados para ler a partir do arquivo de fluxo de transporte é exatamente conhecida para obter um quadro I 201 completo. Se por alguma razão, o final do quadro I não é conhecido, o GOP inteiro ou pelo menos uma grande parte dos dados GOP deve ser lida para assegurar que o quadro I 201 inteiro seja lido. O término do GOP é dado pelo início do próximo quadro I 201. E conhecido a partir de medições, que a quantidade de dados de quadro I pode ser 40% ou mais dos dados GOP totais.
Com os quadros I 201 recuperados, um novo fluxo de truncagem que é conforme ao formato de fluxo de transporte MPEG2 pode ser construído. Tudo que é necessário é que os quadros para os fluxos de quadro P sejam re-multiplexados corretamente, de tal modo que não ocorram problemas de meio de armazenagem temporária para o decodificador MPEG. Embora isto pareça ser uma solução direta, não é uma solução trivial como ficará claro a seguir.
A seguir, alguns aspectos relacionados a como construir um fluxo de truncagem serão descritos.
Com a ajuda do arquivo CPI, descrevendo em qual posição de pacote um quadro I 201 começa, bem como onde o quadro I 201 termina, é provido acesso a todos os quadros I 201 a partir do fluxo original. Porém exatamente concatenando adequadamente os quadros I 201 escolhidos em um grande fluxo somente de quadros I 201, não resulta em um fluxo MPEG válido, como ficará claro a seguir.
O primeiro ponto a investigar é a taxa de bit do fluxo de truncagem. Por exemplo, o fluxo original tem uma taxa de bit de vídeo média de 4 Mbps e um tamanho GOP 203 de 12 quadros. A taxa de bit pode ser extraída de uma medição em um fluxo de radiodifusão real. E suposto que o fluxo de truncagem consiste de quadros I 201 somente que são exibidos cada um em um tempo de quadro, conduzindo a uma taxa de atualização do fluxo de truncagem igual à reprodução normal. É lembrado que a quantidade de dados do quadro I 201 pode ser 40% dos dados GOP. Este número se origina de uma medição, onde a média tem sido em torno de 25%. Assim5 na média, 25% dos dados tem que ser comprimidos em 1/12 do tempo, conduzindo a uma taxa de bit 3 vezes mais alta. Então, a taxa de bit de truncagem média seria de 12 Mbps com picos até em torno de 20 Mbps. Este exemplo simples é destinado a prover algum sentimento para o efeito da taxa de bit e sua origem.
De fato, os tamanhos dos quadros I 201 são conhecidos ou são deriváveis da medição. Portanto, a taxa de bit para um fluxo de truncagem somente de quadro I 201 como uma função do tempo, pode ser facilmente calculada de modo preciso. A taxa de bit de truncagem pode ser 2 a 3 vezes mais alta do que a taxa de bit de reprodução normal e algumas vezes pode ser mais alta do que o permitido pelo padrão MPEG2. Levando em conta que este é um exemplo com um fluxo de taxa de bit moderada e que fluxos com taxas de bits mais altas certamente serão encontrados, está claro que alguma de redução de taxa de bit tem que ser aplicada. Por exemplo, a taxa de bit de truncagem pode ser comparável à taxa de bit de reprodução normal. Isto é especialmente importante se os fluxos são enviados a um decodificador através de uma interface digital. Demanda adicional de largura de faixa a partir da interface, devido à truncagem deveria ser evitada. Uma primeira opção é reduzir o tamanho dos quadros I 201. Entretanto, isto pode adicionar complexidade e limitações em relação à truncagem para fluxos criptografados.
Um opção que pode ser apropriada para aplicações particulares é reduzir a taxa de atualização de imagem de truncagem exibindo cada quadro I 201 várias vezes. A taxa de bit será reduzida correspondentemente. Isto pode ser obtido adicionando assim chamados quadros P 202 vazios entre os quadros I 201. Tal quadro P 202 vazio não é realmente vazio mas pode conter dados instruindo o decodificador a repetir o quadro anterior. Isto tem um custo de bit limitado, o que pode em muitos casos ser desprezado, comparado a um quadro I 201. A partir de experimentos, é sabido que estruturas GOP de truncagem como IPP ou IPPP podem ser aceitáveis para a qualidade de imagem de truncagem e mesmo vantajosas em altas velocidades de truncagem. A taxa de bit de truncagem resultante é da mesma ordem que a taxa de bit normal. E também mencionado que estas estruturas podem reduzir a largura de faixa mantida requerida a partir do dispositivo de armazenagem.
A seguir, alguns aspectos relacionados aos problemas de temporização e construção de fluxo serão descritos.
Um sistema de truncagem 500 é esquematicamente exibido na Figura 5.
O sistema de truncagem 500 compreende uma unidade de gravação 501, uma unidade de seleção de quadro I 502, um bloco de geração de truncagem 503 e um decodificador MPEG2 504. O bloco de geração de truncagem 503 inclui uma unidade de análise 505, uma unidade de adição 506, uma unidade empacotadora 507, uma tabela de unidade de memória 508 e um multiplexador 509.
A unidade de gravação 501 provê a unidade de seleção de quadro I 502 de dados MPEG2 de texto simples 510. O multiplexador 509 provê o decodificador MPEG2 504 de um fluxo de transporte conforme MPEG2 DVB 511.
O seletor de quadro I 502 lê quadros I 201 específicos a partir do dispositivo de armazenagem 501. Quais quadros I 201 são escolhidos, depende da velocidade de truncagem, como será descrito abaixo. Os quadros I recuperados 201 são usados para construir um fluxo de truncagem conforme MPEG2/DVB que é então enviado ao decodificador MPEG2 504 para decodificação e fornecimento. A posição dos pacotes de quadro I no fluxo de truncagem não pode ser acoplada à temporização relativa do fluxo de transporte original. Na truncagem, o eixo dos tempos pode ser comprimido com o fator de velocidade e adicionalmente invertido para truncagem reversa. Portanto, as marcações de tempo do fluxo de transporte de marcação de tempo original podem não ser adequadas para a geração de truncagem.
Ainda mais, a base de tempo PCR original pode ser perturbadora para truncagem. Antes de tudo, não é garantido que um PCR estará disponível dentro do quadro I 201 selecionado. Mas até mais importante, é que a freqüência da base de tempo PCR seria mudada. De acordo com a especificação MPEG2, esta freqüência estaria dentro de 30 ppm a partir de 27 MHz. A base de tempo PCR original satisfaz a essa exigência, mas se é usada truncagem esta seria multiplicada pelo fator de velocidade de truncagem. Para truncagem reversa, isto até conduz a uma base de tempo executada na direção errada. Portanto, a BlueTooth PCR antiga tem que ser removida e uma nova adicionada ao fluxo de truncagem.
Finalmente, quadros I 201 normalmente contém duas marcações de tempo que dizem ao decodificador 504 quando começar a decodificar o quadro (marcação de tempo de decodificação, DTS) e quando iniciar a apresentação, por exemplo visualizando-a (marcação de tempo de apresentação, PTS). Decodificação de apresentação podem ser iniciadas quando DTS e respectivamente PTS são iguais à base de tempo PCR, que é reconstruída no decodificador MPEG2 504 por meio dos PCR no fluxo. A distância entre, por exemplo, os valores PTS de dois (2) quadros I 201 corresponde a sua distância nominal no tempo de visualização. Na truncagem esta distância no tempo é comprimida com o fator de velo. Uma vez que uma nova base de tempo PCR é usada em truncagem, e como a distância para DTS e PTS não é mais correta, o DTS e PTS original do quadro I 201 têm que ser substituídos. Para resolver as complicações acima mencionadas, o quadro I 201 pode ser primeiramente analisado em um fluxo elementar na unidade de análise 505. Então, pois quadros P 202 vazios são adicionados ao nível de fluxo elementar. O GOP de truncagem obtido é mapeado em um pacote PES e empacotado para transportar pacotes de fluxo. As tabelas corrigidas com PAT, PMT, etc., são adicionadas. Neste estágio, uma nova base de tempo PCR juntamente com DTS e PTS são incluídas. Os pacotes de fluxo de transporte são pré pendentes com uma marcação de tempo de 4 bytes que é acoplada à base de tempo PCR, de tal modo que o fluxo de truncagem pode ser processado pelos mesmos circuitos de saída usados para reprodução normal.
A seguir, alguns aspectos relacionados a velocidades de truncagem serão descritos.
Neste contexto, primeiramente, velocidades de truncagem fixas serão discutidas.
Conforme mencionado anteriormente, uma estrutura GOP de truncagem como IPP pode ser usada, na qual dois (2) quadros P vazios 202 seguem o quadro I 201. É suposto que o GOP original possui um tamanho de GOP 203 de 12 quadros e que os quadros I originais 201 são usados para truncagem. Isto significa que os quadro I 201 no fluxo de reprodução normal possui uma distância de 12 quadros e os mesmos quadros I 201 no fluxo de truncagem uma distância de 3 quadros. Isto conduz a uma velocidade de truncagem de 12/3 = 4x. Se o tamanho operação original 203 em quadros é denotado por G, então o tamanho GOP de truncagem em quadros é denotado por Teo fator de velocidade de truncagem por Nb, a velocidade de truncagem em geral é dada por:
Nb = G/T (1)
Nb também será denotado como a velocidade básica. Velocidades mais altas podem ser realizadas pulando quadros 1201 a partir do fluxo original. Se cada segundo quadro I 201 é considerado, a velocidade de truncagem é dobrada, se cada terceiro quadro I 201 é considerado, a velocidade de truncagem é triplicada e assim por diante. Em outras palavras, a distância entre os quadros I 201 usados do fluxo original é 2, 3 e assim por diante. Esta distância pode ser sempre um número inteiro. Denotando a distância entre os quadros I 201 usados para geração de truncagem por D (D=I significando que cada quadro I 201 é usado) então o fator de velocidade de truncagem geral N é dado por:
N = D* G/T (2)
Isto significa que todos os múltiplos inteiros da velocidade básica podem ser realizados, conduzindo a um conjunto aceitável de velocidades. Deveria ser notado que D é negativo para truncagem reversa e que D = O resulta em uma imagem parada. Os dados podem apenas ser lidos em uma direção direta. Portanto, na truncagem reversa, dados são lidos para a frente e são feitos saltos para trás para recuperar o quadro I 201 precedente dados por D. Deveria também ser notado que um tamanho de GOP de truncagem maior T resulta em uma velocidade básica mais baixa. Por exemplo, IPPP conduz a um conjunto de granulação mais fina de velocidades do que IPP.
A seguir, referindo-se à Figura 6, a compressão de tempo na truncagem será explicada.
Figura 6 mostra a situação para T = 3 (IPP) e G = 12. Para D = 2, um tempo de visualização original de 24 quadros é comprimido em um tempo de visualização de truncagem de 3 quadros, resultando em N = 8. No exemplo dado, a velocidade básica é um inteiro, mas este não é necessariamente o caso. Para G = 16 e T = 3, a velocidade básica é 16/3 = 5 1/3, que não resulta em um conjunto de velocidades de truncagem inteiro. Portanto, a estrutura IPPP (T= 4) é melhor adequada para um tamanho de GOP de 16 resultando em uma velocidade básica de 4x. Se uma estrutura de truncagem única é desejada, a qual se ajusta aos tamanhos GOP mais comuns de 12 e 16, IPPP pode ser escolhido
Em segundo lugar, velocidades de truncagem arbitrárias serão discutidas.
Em alguns casos, o conjunto de velocidades de truncagem resultante do método descrito acima é satisfatório, em alguns casos não. No caso de G= 16 e T = 3, provavelmente ainda seriam preferidos fatores de velocidade de truncagem inteiros. Mesmo no caso de G = 12, T = 4 pode ser preferido ter uma velocidade não disponível no conjunto, como por exemplo, 7x. Agora, a fórmula de velocidade de truncagem será invertida e a distância D será calculada, a qual é dada por:
D = N*T/G (3)
Usando o exemplo acima com G = 12, T = 4 e N = 7 resulta em D = 2 1/3. Ao invés de pular um número fixo de quadros I 201, um algoritmo de salto adaptivo pode ser usado, o qual escolhe o próximo quadro I 201 baseado no fato de qual quadro I 201 coincide melhor com a velocidade requerida. Para escolher o quadro I 201 de melhor coincidência, o próximo ponto ideal Ip com a distância D pode ser calculado e um dos quadros I 201 pode ser escolhido mais próximo a este ponto ideal, para construir um GOP de truncagem. Na etapa a seguir, novamente o próximo ponto ideal pode ser calculado aumentando o último ponto ideal de D.
Conforme visualizado na Figura 7, ilustrando truncagem com distâncias fracionárias, há particularmente três possibilidades para escolher o quadro I 201:
A. O quadro I mais próximo do ponto ideal; I = round(Ip) Β. O último quadro I antes do ponto ideal; / = int(Ip) C. O primeiro quadro I após o ponto ideal; / = int(Ip)+1 Como pode ser claramente visto a distância real está variando entre int(D) e int(D)+l, a relação entre as ocorrências das duas sendo dependente da fração de D, de tal modo que a distância média é igual a D. Isto significa que a velocidade de truncagem média é igual a N, mas o quadro usado realmente apresenta uma pequena flutuação de fase com respeito ao quadro ideal. Várias experiências foram executadas com isto, e embora a velocidade de truncagem possa variar localmente, isto não é visualmente perturbador. Usualmente, não é sequer notável, especialmente a velocidades de truncagem algo mais altas. E também claro a partir da Figura 7 que não faz diferença essencial escolher os métodos A, B ou C.
Com este método, a velocidade de truncagem N não necessita ser um inteiro, mas pode ser qualquer número acima da velocidade básica Nb. Também, velocidades abaixo deste mínimo podem ser escolhidas, mas então a taxa de atualização da imagem pode ser reduzida localmente, porque o tamanho T de truncagem GOP efetivo é dobrado, ou, a velocidades ainda mais baixas, até triplicado ou mais. Isto é devido a uma repetição dos GOP de truncagem, pois o algoritmo escolherá o mesmo quadro I 201 mais de uma vez.
Figura 8 mostra um exemplo para D = 2/3 o que é equivalente a N = 2/3 Nb. Aqui, a função de arredondamento é usada para selecionar os quadros I 201 e como pode ser visto os quadros 2 e 4 são selecionados duas vezes.
De qualquer modo, o método descrito permitirá uma velocidade de truncagem variável. Para truncagem reversa, um valor negativo é escolhido para N. Para o exemplo da Figura 7, isto simplesmente significa que as setas 700 estão apontando na outra direção. O método descrito incluirá também os conjuntos de velocidades de truncagem fixas mencionados anteriormente e estes terão a mesma qualidade, especialmente se é usada a função de arredondamento. Portanto, poderia ser apropriado que o método flexível descrito nesta seção deveria sempre ser implementado qualquer que seja a escolha das velocidades. A seguir, alguns aspectos relacionados à taxa de atualização da imagem de truncagem, serão discutidos.
O termo "taxa de atualização" denota particularmente a freqüência com a qual novas imagens são exibidas. Embora não dependente da velocidade será brevemente discutido aqui porque pode influenciar a escolha de T. Se denotarmos a taxa de atualização da imagem original por R (25 Hz ou 30 Hz) a taxa de atualização da imagem de truncagem (Rt) é dada por:
Rt = R/T (4)
Com uma estrutura GOP de truncagem de IPP (T = 3) ou IPPP (T = 4) a taxa de atualização Rt é 8 1/3 Hz respectivamente 6 1/4 Hz para a Europa e 10 Hz respectivamente 7 e 1/2 Hz para os USA. Embora o julgamento da qualidade de imagem da truncagem seja um assunto algo subjetivo, há sugestões claras de experiências que estas taxas de atualização são aceitáveis para baixas velocidades e mesmo vantajosas a velocidades mais altas.
A seguir, alguns aspectos relacionados aos ambientes de fluxo criptografados serão descritos.
A seguir, alguma informação sobre fluxos de transporte criptografados é apresentada como uma base para a descrição de truncagem em fluxos criptografados. Isto é focalizado no Sistema de Acesso Condicional usado para radiodifusão.
Figura 9 ilustra um sistema de acesso condicional 900 que será descrito a seguir.
No sistema de acesso condicional 900, o conteúdo 901 pode ser provido a uma unidade de criptografia de conteúdo 902. Após ter criptografado o conteúdo 901, a unidade de criptografia de conteúdo 902 fornece a uma unidade de descriptografia de conteúdo 904, conteúdo criptografado 903. Uma palavra de controle 906 pode ser fornecida à unidade de criptografia de conteúdo 902 e a uma unidade de geração ECM 907. A unidade de geração ECM 907 gera uma ECM e provê a mesma a uma unidade de decodificação de ECM 908 de um cartão inteligente 905. A unidade de decodificação de ECM 908 gera a partir da ECM uma palavra de controle que é informação de descriptografia que é necessária e provida à unidade de descriptografia de conteúdo 904, para descriptografar o conteúdo criptografado 903.
Ainda mais, um código de atualização 910 é provido à unidade de geração ECM 907 e a uma unidade de geração KMM 911 onde a última gera uma KMM e provê a mesma a uma unidade de decodificação KMM 912 do cartão inteligente 905. A unidade de decodificação KMM 912 provê um sinal de saída à unidade de decodificação de ECM 908.
Ainda mais, um código de grupo 914 pode ser provido à unidade de geração KMM 911 e a uma unidade de geração GKM 915 que pode adicionalmente ser provida com um código de usuários 918. A unidade de geração GKM 915 gera um sinal GKM e provê o mesmo a uma unidade de decodificação GKM 916 do cartão inteligente 905, onde a unidade de decodificação GKM 916 obtém como uma entrada adicional um código de usuário 917.
Além disto, intitulações 919 podem ser providas a uma unidade de geração EMM 920 que gera um sinal EMM e provê o mesmo a uma unidade de decodificação EMM 921. A unidade de decodificação EMM 921 localizada no cartão inteligente 905 é acoplada a uma unidade de lista de intitulação 912 que provê a unidade de decodificação de ECM 908 da informação de controle correspondente.
ECM denota Mensagens de Controle de Intitulação, KMM denota Mensagens de Gerenciamento de Código, GKM denota Mensagens de Códigos de Grupo, e EMM denota Mensagens de Gerenciamento de Intitulação.
Em muitos casos, provedores de conteúdo e provedores de serviço desejam controlar o acesso a certos itens de conteúdo através de sistema de acesso condicional (CA).
Para obter isto, o conteúdo 901 radiodifundido é criptografado sob controle do sistema de acesso condicional 900. No receptor, o conte é descriptografado antes da decodificação e entrega, se o acesso é autorizado pelo sistema de acesso condicional 900.
O sistema de acesso condicional 900 usa uma hierarquia em camadas (ver Figura 9). O sistema de acesso condicional 900 transfere o código de descriptografia do conteúdo (palavra de controle CW 906, 909) do servidor para o cliente na forma de uma mensagem criptografada, chamada Mensagens de Controle de Intitulação (ECM). As ECM são criptografadas usando um código de autorização (AK) 910. Por razões de segurança, o servidor de CA 900 pode renovar o código de autorização 910 emitindo uma KMM (Mensagens de Gerenciamento de Código). Uma KMM é de fato um tipo especial de EMM (Mensagem de Gerenciamento de Intitulação) mas para clareza o termo KMM pode ser usado. As KMM são também criptografadas usando um código que, por exemplo, pode ser um código de grupo (GK) 914, que é renovado enviando uma GKM (Mensagem de Código de Grupo) que é novamente um tipo de EMM. Os GKM são então criptografados com o código de usuários (UK) 917, 918 que é um código único fixo embutido no cartão inteligente 905 e conhecido pelo sistema CA 900 do provedor somente. Códigos de autorização e códigos de grupo são armazenados no cartão inteligente 905 do receptor.
Intitulações 919 (por exemplo direitos de visualização) são enviados a usuários individuais na forma de uma EMM (Mensagem de Gerenciamento de Intitulação) e armazenados localmente em um dispositivo seguro (cartão inteligente 905). Intitulações 919 são acopladas a um programa especifico. Uma lista de intitulações 913 dá acesso a um gravação de programas dependendo do tipo de subscrição. As ECM são somente processadas em códigos (palavras de controle) pelo cartão inteligente 905, se uma intitulação 919 estiver disponível para o programa específico. As EMM de intitulações estão sujeitas a uma estrutura em camadas idêntica às KMM (não mostrado na Figura 9).
No sistema MPEG2, conteúdo criptografado, ECM e EMM (incluindo os tipos KMM e GKM) são todos multiplexados em um único fluxo de transporte MPEG2.
A descrição acima é uma visão generalizada do sistema de acesso condicional 900. Na radiodifusão de vídeo digital, somente o algoritmo de criptografia, a estrutura de palavra de controle impar/par, a estrutura global das ECM e EMM e seu referenciamento são definidos. A estrutura detalhada do sistema de acesso condicional 900 e o meio pelo qual as cargas úteis das ECM e EMM são codificadas e usadas são específicos do provedor. Também o cartão inteligente é específico do primeiro valor digital. Entretanto, por experiência é sabido que muitos provedores seguem essencialmente a estrutura da visão generalizada da Figura 9.
A seguir, tópicos de Criptografia/Descriptografia DVB serão discutidos.
O algoritmo de criptografia e descriptografia é definido pela organização de padronização DVB. Em princípio, duas possibilidades de criptografia são definidas, a saber, criptografia de nível PES e criptografia de nível TS. Entretanto, na vida real, principalmente o método de criptografia de nível TS é usado. A criptografia e descriptografia de pacotes de fluxos de transporte são feitas baseadas em pacotes. Isto significa que o algoritmo de criptografia e descriptografia é reiniciado cada vez que um novo pacote de fluxo de transporte é recebido. Portanto, pacotes podem ser criptografados ou descriptografados individualmente. No fluxo de transporte, pacotes criptografados e texto simples são misturados e algumas partes do fluxo são criptografadas (por exemplo, áudio/vídeo) e outras não (por exemplo, tabelas). Mesmo dentro de uma parte de fluxo (por exemplo, vídeo) criptografado e texto simples, pacotes podem ser misturados). A seguir, referindo-se à Figura 10, um pacote de fluxo de transporte criptografado DVB 1000 será descrito.
O pacote de fluxo 1000 tem uma extensão 1001 de 188 bytes que compreende três porções. Um cabeçalho de pacote 1002 tem um tamanho 1003 de 4 bytes. Subseqüentemente ao cabeçalho de pacote 1002, um campo de adaptação 1004 pode ser incluído no pacote de fluxo 1000. Depois disso, uma carga útil de pacote criptografado DVB 1005 pode ser enviada.
Figura 11 ilustra uma estrutura detalhada do cabeçalho de pacote de fluxo de transporte 1002 da Figura 10.
O cabeçalho de pacote de fluxo de transporte 1002 compreende uma unidade de sincronização (SYNC) 1010, um indicador de erro de transporte (TEI) 1011 que pode indicar erros de transporte em um pacote, um indicador de início de unidade de carga útil (PLUSI) 1012 que pode indicar particularmente um possível início de um pacote PES na carga útil subseqüente 1005, uma unidade de prioridade de transporte (TPI) 1017 indicando prioridade de transporte, um identificador de pacote (PID) 1013 usado para determinar a designação do pacote, um controle de mistura de transporte (SCB) 1014 é usado para selecionar o CW que é necessário para descriptografar o pacote de fluxo de transporte, um controle de campo de adaptação (AFLD) 1015, e um contador de continuidade (CC) 1016. Então, a Figura IOe Figura 11 mostram o pacote de fluxo de transporte MPEG2 1000 que foi criptografado e que compreende diferentes partes:
- Cabeçalho de pacote 1002 está em texto simples. Este serve para obter informação importante tal como um número de identificador de pacote (PID), a presença de um campo de adaptação, bits de controle de mistura, etc.
- Campo de adaptação 1004 está também com texto simples. Este pode conter informação de temporização importante tal como PCR.
- Carga Útil de Pacote Criptografado DVB 1005 contém o conteúdo de programa real que pode ter sido criptografado usando o algoritmo DVB.
No sentido de selecionar as CW corretas que são necessárias para descriptografar o programa radiodifundido, é necessário analisar o cabeçalho de pacote de fluxo de transporte. Uma visão geral esquemática deste cabeçalho é dada na Figura 11. Um campo importante para a descriptografia do programa radiodifundido é o campo de bits de controle de mistura (SCB) 1014. Este campo SCB 1014 indica quais CW o descriptografador precisa usar para descriptografar o programa radiodifundido. Ainda mais, indica se a carga útil do pacote é criptografada ou em texto simples. Para cada novo pacote de fluxo de transporte, este campo SCB 1014 precisa ser analisado, uma vez que este muda ao longo do tempo e pode mudar de pacote a pacote.
A seguir, alguns aspectos relacionados à truncagem em fluxos plenamente criptografados, serão descritos.
A primeira razão pela qual este é um tópico interessante é que truncagem em texto simples e fluxos plenamente criptografados são os dois extremos de uma faixa de possibilidades. Uma outra razão é que existem aplicações nas quais pode ser necessário gravar fluxos plenamente criptografados. Então, seria útil ter uma técnica em mãos para efetuar truncagem em um fluxo plenamente criptografado. Um princípio básico é ler um bloco de dados grande o bastante a partir do dispositivo de armazenagem, descriptografá-lo, selecionar um quadro I no bloco e construir um fluxo de truncagem com o mesmo.
Tal sistema 1200 é exibido na Figura 12. Figura 12 mostra um princípio básico de truncagem em um fluxo plenamente criptografado. Para esta finalidade, dados armazenados em um disco rígido 1201 são providos como um fluxo de transporte 1202 para um descriptografador 1203. Adicionalmente, o disco rígido 1201 provê um cartão inteligente 1204 com uma ECM, onde o cartão inteligente 1204 gera palavras de controle a partir desta ECM e envia as mesmas ao descriptografador 1203.
Usando as palavras de controle, o descriptografador 1203 descriptografa o fluxo de transporte criptografado 1202 e envia os dados criptografados a um detector de quadro I e filtro 1205. A partir daí, os dados são providos a uma unidade de inserção de quadro P vazio 1206 que conduz os dados a um "conversor de caixa de topo" 1207. A partir daí, os dados são providos a uma televisão 1208.
A seguir, alguns aspectos serão mencionados com respeito à questão do que uma gravação contém.
Efetuando uma gravação de um canal único, a gravação precisa conter todos os dados requeridos para reproduzir a gravação do canal em um estágio posterior. Pode-se recorrer a apenas gravar tudo em um certo transponder, mas deste modo poder-se-ia gravar muito mais do que o necessário para reproduzir o programa destinado a gravar. Isto significa que ambos largura de faixa e espaço de armazenagem seriam gastos. Assim, ao invés disso, somente os pacotes realmente necessários deveriam ser gravados. Para cada programa, isto significa que é necessário gravar todos os pacotes mandatórios MPEG2 como PAT (tabela de associação de programa), CAT (tabela de acesso condicional), e obviamente para cada programa os pacotes de vídeo e áudio, bem como a PMT (tabela de mapa de programa) que descreve quais pacotes pertencem a um programa. Adicionalmente, a CAT/PMT pode descrever pacotes CA (ECM) necessários para descriptografar o sistema. A menos que a gravação seja feita em texto simples após a descriptografia, aqueles pacotes ECM têm que ser gravados.
Se a gravação feita não consiste de todos os pacotes a partir do multiplex pleno, a gravação se torna um assim chamado fluxo de transporte parcial 1300 (ver Figura 13). Adicionalmente, Figura 13 ilustra um fluxo de transporte pleno 1301. O padrão DVB requer que, se um fluxo de transporte parcial 1300 é reproduzido, todas as tabelas mandatórias DVB normais como NIT (tabela de informação de rede), BAT (tabela de associação de buquê), etc. são removidas. Ao invés destas tabelas, o fluxo parcial deveria ter SIT (tabela de informação de seleção) e DIT (tabela de informação de descontinuidade) inseridas.
A seguir, referindo-se à Figura 14 à Figura 36, serão descritos sistemas que são capazes de processar um fluxo de dados de acordo com realizações típicas da invenção.
E enfatizado que os sistemas descritos a seguir podem ser implementados no quadro e em combinação com qualquer dos sistemas descritos, referindo-se à Figura 1 à Figura 13.
A seguir, aspectos relacionados à truncagem em sistemas híbridos serão descritos.
A seguir, quadros I de texto simples serão discutidos.
Uma gravação na qual os quadros I 201 estão em texto simples e o restante criptografado é uma alternativa a um fluxo de texto simples pleno, a partir do ponto de vista de funcionalidade de armazenagem especial como avanço rápido/reverso.
A seguir, referindo-se à Figura 14, um sistema 1400 para transmitir dados entre um radiodifusor 1401 e dispositivos de armazenagem 1406, 1408 e 1409 de acordo com uma realização típica da invenção, serão descritos.
Um radiodifusor 1401 transmite dados a um refletor de satélite 1402 a partir do qual, via um satélite 1403, os dados são providos a um refletor de satélite 1404. A partir do refletor de satélite 1404, os dados são providos a uma extremidade principal de cabo 1405, a um ponto de conexão residencial 1407 e a um dispositivo de armazenagem 1409. A partir da extremidade principal de cabo 1405, os dados podem ser adicionalmente transmitidos ao dispositivo de armazenagem 1406. A partir do ponto de conexão residencial 1407, os dados podem ser adicionalmente transmitidos a um dispositivo de armazenagem 1408.
Conforme mostrado na Figura 14 particularmente quatro métodos diferentes são possíveis de como um fluxo de texto simples de quadro I pode ser gerado. Conforme denotado por "1", o radiodifusor 1401 pode gerar um fluxo de texto simples de quadro I. Conforme denotado pó "2", o cabo principal 1405 pode gerar um fluxo de texto simples de quadro I. Conforme denotado por "3", o ponto de conexão residencial 1407 pode gerar um fluxo de texto simples de quadro I. Conforme denotado por "4", o dispositivo de armazenagem 1409 pode gerar um fluxo de texto simples de quadro I.
Conforme exibido na Figura 14, há vários locais na cadeia de suprimento onde tal fluxo poderia ser construído.
Opções "1" e "2" podem ser situações favoráveis nas quais não são necessárias ações no equipamento de consumidor. No caso "3", as ações podem ser limitadas a apenas um dispositivo doméstico sendo o ponto de conexão residencial 1407. A opção "4" pode ser mais realista.
Na entrada da própria unidade de armazenagem, o fluxo agora pode conter pelo menos quadros I de texto simples e o restante pode ser criptografado ou também em texto simples, dependendo da espécie de transmissão que está sendo armazenada. Isto significa que em todos os casos, os dados CPI relacionados aos pontos de início e términos de quadros I podem ser gerados. Os dados recuperados usando os dados CPI durante truncagem agora somente contém quadros I de texto simples. Isto significa que, para o sistema de truncagem, pode não haver diferença entre truncagem em um fluxo plenamente de texto simples e tal fluxo híbrido.
A seguir, aspectos relacionados a pacotes de texto simples serão descritos.
Uma possibilidade é que o fluxo de truncagem gerado seja completamente de texto simples, se o fluxo original for texto simples ou (parcialmente) criptografado. Isto não é um problema se a máquina de truncagem e o decodiflcador/fornecedor estiverem em um e no mesmo dispositivo. Porém, se o fluxo de truncagem é criado dentro de um servidor e então distribuído através de uma rede, ter o fluxo de truncagem em texto simples pode não ser desejado ou permitido pelo provedor de conteúdo. O mesmo pode ser verdadeiro para reprodução normal.
A seguir, referindo-se à Figura 15, um sistema 1500 será descrito relacionado à truncagem em uma gravação de texto simples.
Uma unidade de gravação 1501 é conectada a uma unidade de seletor de quadro 1503 e provê a última de dados MPEG2 de texto simples 1502. A unidade de seletor de quadro 1503 é acoplada a uma unidade de geração de truncagem 1504 que provê um decodiflcador MPEG2 1506 de um fluxo de transporte conforme a MPEG2 DVB 1505.
Se o fluxo gravado original está em texto simples conforme exibido na Figura 15, não haveria problema de que o fluxo de truncagem fosse também em texto simples. Mas mesmo em um fluxo que foi gravado enquanto ainda era plenamente criptografado, um fluxo de truncagem pode ser gerado, o qual é plenamente em texto simples, conforme mostrado na Figura 16.
Em adição ao sistema 1500, o sistema 1600 compreende adicionalmente uma unidade de seletor de bloco 1602 que é provida de dados MPEG2 criptografados 1601 a partir do dispositivo de gravação 1501. Adicionalmente, uma unidade de descriptografador 1603 é provida entre a unidade de seletor de bloco 1602 e a unidade de seletor de quadro 1503.
Nesta situação, um fluxo de truncagem de texto simples pode não ser desejável. Sob circunstâncias particulares pode não ser possível simplesmente pular o descriptografador pois nenhum fluxo de truncagem pode ser construído a partir de um fluxo plenamente criptografado. Uma solução poderia ser criptografar o fluxo de truncagem de texto simples novamente. Pode ser necessário ajustar qual algoritmo de programação de código (CW, ECM5 etc.) e criptografia deveria ser usada. Por exemplo, pode não ser permitido adicionar um criptografador DVB a um dispositivo de usuário, e assim um outro formato de criptografia deveria ser escolhido em tal caso. Este poderia ser uma outra cifragem com DES, 3DES, AES, etc. Fazer isto significaria que os "conversores de caixa de topo" (STB) atuais não são capazes de descriptografar o fluxo de truncagem. Além disto, a reprodução normal é realizada realizando streaming no fluxo criptografado DVB original para STB, sem quaisquer modificações no nível de criptografia. Assim, um conversor adaptado não só necessitaria ser capaz de descriptografar um outro formato como teria também que ser capaz de decidir qual dos formatos utilizar em qual parte do fluxo recebido. Isto pode ser não trivial porque tal indicação não está presente no próprio fluxo. Inerentemente, truncagem teria que ser processada diferentemente da reprodução normal.
Uma solução desejável seria que ambos reprodução normal e truncagem estivessem no formato de criptografia DVB, mas pode não ser permitido usar um criptografador DVB.
A seguir, uma solução básica para o problema de criptografia será descrita.
Será explicado como é possível gerar um fluxo de truncagem criptografado DVB mesmo num cenário no qual o uso de uma máquina de criptografia DVB doméstica não seja permitido. Primeiramente, é notado que um fluxo de truncagem criptografado deveria somente ser necessário se o fluxo de reprodução normal original fosse também criptografado. Com isto em mente, o fluxo de truncagem pode ser construído diretamente a partir dos pacotes de feixe de radiação de reprodução normal criptografados. Isto implica em que a geração de um fluxo de truncagem no nível de fluxo elementar pode não ser mais possível. Este deveria ser gerado diretamente no nível do fluxo de transporte.
Para esta geração de truncagem, pode ser pelo menos necessário saber onde estão localizados os quadros I no fluxo de transporte de reprodução normal criptografado. Isto poderia ser obtido descriptografando o fluxo, detectando os quadros I e gerando apontadores para o início e fim do quadro I no fluxo criptografado. Porém, para a geração de um fluxo de truncagem válido pode ser necessário alterar alguns dados na carga útil criptografada de alguns pacotes. Isto pode somente ser feito se estes pacotes são primeiramente descriptografados e então adaptados. Entretanto, os pacotes adaptados não podem ser re-criptografados. Portanto, alguns pacotes no fluxo de truncagem sempre serão em texto simples. Preferivelmente, estes pacotes já estão gravados em texto simples. Estes pacotes em texto simples então permitem também uma detecção direta da posição de quadro I que é então armazenado no arquivo CPI.
Truncagem em uma gravação parcialmente criptografada é ilustrado na Figura 17.
No sistema 1700 mostrado na Figura 17, quando comparado com a Figura 15, a unidade de seletor de quadro 1503 é provida de dados MPEG2 parcialmente criptografados 1701, pela unidade de gravação 1501. Adicionalmente, a unidade de geração de truncagem 1504 provê um decodificador MPEG2 e a unidade de descriptografador 1703 de um fluxo de transporte conforme a MPEG2 DVB 1702, sendo parcialmente criptografado.
A quantidade de dados de texto simples no fluxo deveria ser minimizada de tal modo a ser efetivamente ainda com fluxo criptografado bem protegido. A seguir, o termo "fluxo híbrido" pode indicar tal fluxo.
A seguir, serão descritas quais partes de um fluxo de dados deveriam ser minimamente em texto simples.
Conforme mencionado acima, não apenas tudo é descriptografado, mas também o que é realmente necessário. Para descobrir o que é necessário, um fluxo de radiodifusão prático foi analisado.
- Além das descontinuidades no contador de continuidade, que está localizado no cabeçalho de pacote de texto simples, as primeiras coisas que necessitam ser adaptadas são os campos PTS/DTS no cabeçalho PES.
Assim, é necessário que o pacote de fluxo de transporte que contém aqueles campos seja em texto simples. Isto também significa que o pacote no qual o quadro I começa é usualmente em texto simples.
- A próxima coisa que pode estar errada é o último pacote do quadro I, que pode também conter o início do próximo quadro P ou quadro B.
Assim aquele pacote pode ser corrigido removendo todos os dados não de quadro I e enchendo o pacote. Portanto, este pacote deveria ser também em texto simples.
- Todos os pacotes entre estes dois apenas contém dados de vídeo de quadro I que podem ser usados como são e portanto, permanecem criptografados.
- Para adicionar quadros vazios corretos, pode ser necessário conhecer a resolução da imagem, e adicionar uma nova base de tempo que pode ser necessária para conhecer a taxa de quadro. Todos os dados necessários podem ser encontrados nos campos de cabeçalho PES/ES.
Não é garantido que os cabeçalhos PES/ES inteiros estejam no pacote com o PLUSI. Se todos os dados de cabeçalho não estão em um pacote, o(s) próximo(s) pacote(s) é ou são necessário em texto simples, de tal modo que há acesso aos campos descritos abaixo.
No cabeçalho PES, garantido para iniciar no pacote PLUSI, pode ser necessário alterar três campos:
- PES_packet_length
- PTS (marcação de tempo de apresentação)
- DTS (marcação de tempo de decodificação)
PTS e DTS não são mandatórios. Estes deveriam entretanto, ser alterados quando estão presentes.
Para criar o tipo correto de quadros P vazios, para adicionar a nova base de tempo e para corrigir a referência temporal do quadro I, alguns dados dos cabeçalhos ES podem ser necessários:
- Horizontal_size_value
- Vertical_size_value
- Frame_rate_code
Na extensão de seqüência, há uma marcação que pode ser importante:
- Marcação de seqüência progressiva
No cabeçalho de imagem, um item pode necessitar ser modificado:
- Referência temporal
Finalmente, a partir da extensão de codificação de imagem, pode ser necessário acessar estes dois campos:
- Picture_structure
- Top_field_first
Após recuperar estes dados, é possível decidir sobre o tipo de quadro vazio que será adicionado. É possível usar uma tabela de busca previamente criada, que contém quadros vazios criados para todas as combinações possíveis acima, levando em conta as restrições MPEG2. Embora as especificações não requeiram que todos estes campos estejam presentes para cada GOP, acredita-se que nenhum sinal de radiodifusão exista que tenha pulado estes campos. Uma razão pode ser que um decodificador também necessitará ter acesso a estes cabeçalhos para decodificar os dados corretamente tão rápido quanto possível, após eliminar estações.
Assim, tudo que pode ser necessário em texto simples para cada quadro I são uns poucos pacotes, pelo menos um no início e um no fim. Isto tem também a vantagem de que é possível determinar facilmente a posição exata de cada quadro I. Fluxos somente com estes pacotes em texto simples são efetivamente ainda completamente criptografados. O primeiro pacote de cada quadro I usualmente contém quase nenhum dado de vídeo, mas existem somente dados de cabeçalho (P)ES. O último pacote do quadro I pode também conter alguns dados do quadro P ou quadro B, mas isto será removido de qualquer maneira.
A seguir, será discutido como selecionar os pacotes que serão em texto simples.
Quando um fluxo híbrido é construído, deveria ser decidido quais pacotes deveriam ser em texto simples. Para habilitar a detecção e seleção de dados de texto simples necessários, o fluxo de vídeo pode ser primeiro completamente descriptografado. Então, a localização destes dados pode ser determinada no fluxo de texto simples e os pacotes de texto simples nos quais está localizado podem substituir os pacotes criptografados no fluxo original, para formar o fluxo híbrido.
Para selecionar os dados de texto simples, os três critérios seguintes podem ser usados:
1. O DTS/PTS no cabeçalho PES pode ser mudado se estes estão presentes. Para esta finalidade, todos os dados do cabeçalho PES podem ser colocados em texto simples. Isto significa que os pacotes variando a partir daquele com o conjunto de bits PLUSI para aquele contendo o último bit do cabeçalho PES podem ser todos colocados em texto simples.
2. Algumas informações a partir do cabeçalho de seqüência e extensão de seqüência podem ser necessárias. Para esta finalidade, todos os dados a partir do cabeçalho de seqüência até o código de início de imagem podem ser colocados em texto simples. O cabeçalho de seqüência e código de início de imagem podem ser detectados verificando um código de quatro bytes. Estes quatro bytes não estão necessariamente localizados em um e no mesmo pacote. O cabeçalho de seqüência e código de início de imagem são detectados quando o último dos quatro bytes é encontrado. Para evitar a armazenagem temporária excessiva para a construção do fluxo híbrido, os pacotes variando a partir de um contendo o quarto byte do cabeçalho de seqüência até aquele contendo o quarto byte do código de início de imagem podem ser todos colocados em texto simples. Isto pode conduzir a algumas situações peculiares ao buscar o cabeçalho de seqüência e o código de início de imagem no fluxo híbrido resultante.
3. O código de início de imagem pode ser necessário para detectar os limites de quadro. Assim, um pacote contendo um código de início de imagem deveria ser colocado em texto simples. Os dois bytes seguindo o código de início de imagem deveriam também ser em texto simples. Estes bytes contém a referência temporal que pode ser necessária para ser trocada e o tipo de codificação de imagem que identifica um quadro I, quadro P ou quadro B. Ainda mais, alguma informação pode ser necessária a partir da extensão de codificação de imagem. Para esta finalidade, todos os dados do código de início de imagem até o final da extensão de codificação de imagem podem ser colocados em texto simples. O código de início de imagem pode ser detectado quando o quarto byte é encontrado. Para evitar excessiva armazenagem temporária, os pacotes variando daquele contendo o quarto byte do código de início de imagem até aquele contendo o último byte da extensão de codificação de imagem podem ser todos colocados em texto simples. Isto resultará nos pacotes de texto simples em todos os limites de quadro, o que é mais do que o necessário para a construção dos fluxos de truncagem discutidos até então. Porém, pode ser necessário para a construção de um fluxo direto de movimento lento.
A seguir, será explicado o que significa excessiva armazenagem temporária e o que a causa. Se um sistema híbrido é construído, pacotes a partir do fluxo criptografado original e fluxo descriptografado podem ser combinados em um fluxo. Se feito em tempo real, alguma armazenagem temporária pode ser necessária. Pode ser suposto que o código de início de imagem é espalhado através de dois pacotes de vídeo. Este código de início de imagem de 4 bytes pode ser detectado no fluxo descriptografado no momento em que o último byte é encontrado. Ter o código de início de imagem completo em texto simples significa que, não só o pacote de vídeo com este último byte deveria estar em texto simples, como também o pacote de vídeo precedente.
Outros dados podem estar e estarão regularmente entre estes dois pacotes de vídeo. Em princípio, isto pode constituir uma grande quantidade de pacotes.
A seguir, referindo-se à Figura 18, um sistema 1800 será descrito, mostrando a demanda de armazenagem temporária para código de início de imagem completamente de texto simples.
Na Figura 18, um meio de armazenagem temporária 1800 é mostrado, começando com um quadro I 1801 possuindo na extremidade deste uma parte do código de início de imagem 1802. Subseqüentemente, um bloco de áudio 1803 é mostrado. Um bloco de áudio adicionado é mostrado. Ainda mais, um bloco PSI 1805 e um bloco de dados 1806 são mostrados. Em um momento de detecção de código de início de imagem 1807, um bloco compreendendo uma parte do código de início de imagem 1808 e um quadro P subseqüente 1809 é iniciado.
Figura 18 mostra um exemplo de uma situação em que o código de início de imagem ao término do quadro I é espalhado através de dois pacotes de vídeo. Neste caso, não só estes dois pacotes de vídeo têm que ser armazenados temporariamente, como também todos os pacotes com outros dados entre estes dois pacotes de vídeo. Embora o código de início de imagem seja mostrado no exemplo, será claro que o mesmo argumento é válido para o código de cabeçalho de seqüência. Os critérios dados reduzem a armazenagem temporária necessária para somente um pacote. Se um dos três critérios definidos é satisfeitos, pacotes correspondentes serão colocados em texto simples. A combinação dos três critérios freqüentemente conduzirá somente a um pacote de texto simples em cada limite de quadro. Entretanto, em alguns casos práticos para alguns fluxos, podem ser uns poucos pacotes. Teoricamente, pode até ser um grande número de pacotes.
Um primeiro exemplo é um fluxo composto somente de quadros I e quadros P com um tamanho GOP de 12 quadros e um pacotes PES por GOP. Nas experiências executadas, o número de pacotes de texto simples no início do quadro I tem sido sempre um. O número de pacotes de texto simples ao término do quadro I e de fato em todos os outros limites de quadro é usualmente um, mas pode algumas vezes ser dois. No início do quadro I, tudo do cabeçalho PES até a extensão do código de imagem está em um pacote. Os pacotes de texto simples em outros limites de quadro contém todos os dados a partir do código de início de imagem até o término da extensão de codificação de imagem. Estes dados podem ser espalhados através de dois pacotes.
Um segundo exemplo é um fluxo composto de quadros I, quadros P e quadros B com uma estrutura IBP, um tamanho GOP variável até mesmo com valores variando de 2 a 12, e um pacotes PES por quadro. 0 número de pacotes de texto simples no início do quadro I tem sido principalmente dois e ao término do quadro I e outros limites de quadro, sempre um. Os dois pacotes no início do quadro I são principalmente devidos à presença de uma tabela de quantização no cabeçalho de seqüência. Ao término do quadro I e outros limites de quadro, os dados do cabeçalho PES para extensão de codificação de imagem estão todos em um pacote.
Deveria ser notado que, devido à estrutura PES para o segundo exemplo, não é o último pacote do quadro I que está em texto simples, mas de fato o primeiro pacote do próximo quadro. Para o primeiro exemplo, isto pode também ocorrer algumas vezes. Isto não é problema, porque o último pacote do quadro I somente contém dados de quadro I neste caso, e não necessita ser limpo. Deveria ser notado que, na prática, a combinação dos três critérios de seleção conduz a uma área de vídeo de texto simples contígua em cada limite de quadro. Na teoria este não precisa ser o caso. A combinação dos critérios 2 e 3 sempre conduz a uma área contígua, mas teoricamente a área de cabeçalho PES de texto simples pode ser separada.
A seguir, será explicado como encontrar a informação necessária no fluxo híbrido.
Conforme mencionado acima, pode haver na prática uma área de texto simples contígua em cada limite de quadro. No início do quadro I (GOP) os dados de texto simples correm do primeiro byte do cabeçalho PES para pelo menos o último byte da extensão de codificação de imagem. Um exemplo é dados na Figura 19. Todos os dados necessários estão nesta área e podem facilmente ser encontrados analisando esta parte do fluxo que começa em um pacote marcado com um PLUSI.
A seguir, referindo-se à Figura 19, uma área de texto simples prática no início de um quadro I será explicada.
O fluxo de dados mostrado na Figura 19 inclui um primeiro pacote de quadro I 1900 e um segundo pacote de quadro I subseqüente 1901. O primeiro pacote de quadro I 1900 compreende um cabeçalho PES 1902, um cabeçalho de seqüência 1903, uma extensão de seqüência 1904, um cabeçalho GOP 1905, um código de início de imagem 1906 e um cabeçalho de imagem 1907. Adicionalmente, o segundo pacote de quadro I 1901 inclui também o cabeçalho de imagem 1907, uma extensão de codificação de imagem 1908 subseqüente e um bloco de dados de quadro I 1909.
A seguir, os fluxos de dados mostrados na Figura 20A e Figura 20B serão descritos.
No fluxo de dados da Figura 20A, o final de um quadro I 2000 é indicado. Um PLUSI 2001 precede um cabeçalho PES 1902, e então um código de início de imagem 1906 é provido. Depois disso, um cabeçalho de imagem 1907 é enviado, e então uma extensão de codificação de imagem 1908. Subseqüentemente, segue um bloco de dados de quadro P ou quadro B 2003.
No fluxo de dados da Figura 20B, um último quadro I de dados 2004 termina no final de um quadro I 2005, e depois disso um código de início de imagem 1906, cabeçalho de imagem 1907, uma extensão de codificação de imagem 1908 e um bloco de dados de quadro P ou B 2003 se seguem.
No término do quadro I, há na prática duas possibilidades.
1. No caso de um pacote PES por quadro, a área de texto simples no (após) final do quadro I 2000 também começa com o primeiro byte do cabeçalho PES 1902 e corre até pelo menos o último byte da extensão de codificação de imagem 1908. Todos os dados necessários podem ser facilmente encontrados e nenhuma limpeza do último pacote do quadro I é necessária (ver Figura 20A).
2. No caso de um pacote PES por GOP, não há cabeçalho PES após o final do quadro I. Na prática, também não há cabeçalho de seqüência nesta posição. Neste caso, os pacotes contendo o quarto byte do código de início de imagem 1906 até o último byte da extensão de codificação de imagem 1908 estão em texto simples (ver Figura 20B). O código de início de imagem 1906 de quatro bytes poderia ser espalhado através de dois pacotes, por exemplo, os primeiros três bytes em um pacote e o último byte no próximo pacote. Neste caso, os primeiros três bytes podem ainda ser criptografados. Isto parece implicar em que este código de início de imagem 1906 não possa ser detectado no sistema híbrido. Como este problema pode ser resolvido, será descrito posteriormente.
Pode haver de fato uma área de texto simples em cada limite de quadro, assim, detectar o término de um quadro I significa uma busca para o primeiro código de início de imagem após aquele para o quadro I. Seria claro que apenas os pacotes de vídeo de texto simples deveriam ser buscados para este código, para evitar uma falsa coincidência positiva nos dados criptografados. Se a carga útil de um pacote está em texto simples ou não, é indicado pelos bits de controle de mistura no cabeçalho de pacote. A detecção dá uma coincidência positiva somente quando uma seqüência dada de 4 bytes é encontrada (0x00 0x00 0x01 0x00). Esta seqüência corresponde a um código de início de imagem desprezando o tipo de quadro. Infelizmente, o código de início de imagem não tem que ser alinhado nos limites de pacote de fluxo de transporte. Isto significa que, se o código de início de imagem fosse espalhado através de dois pacotes, somente o segundo daqueles pacotes seria em texto simples. Esta situação é mostrada na Figura 21.
Na Figura 21, um cabeçalho de pacote é indicado pelo numerai de referência 2100, um texto simples de carga útil de pacote é indicado pelo numerai de referência 2101, e uma carga útil de pacote criptografada é indicada pelo numerai de referência 2102.
Uma linha superior 2103 indica um código de início de imagem que está completamente localizado no segundo pacote. Para a linha inferior 2104, este está completamente no primeiro pacote. As linhas restantes 2105 indicam três possibilidades para um código de início de imagem espalhada. Pode se esperar que seja impossível detectar um código de início de imagem parcialmente criptografado. Entretanto, há um caminho para fora deste dilema. Cada área de texto simples contém um código de início de imagem ou pelo menos o último byte deste. Assim, se nenhum código de início de imagem é encontrado em uma área de texto simples, é sabido que esta área precisa começar com alguns dos últimos bytes do código de início de imagem. Este número de bytes pode ser um, dois ou três conforme mostrado na Figura 21. Pode ser possível detectar exatamente quantos bytes há. A este respeito é notado que os três bits do tipo de codificação de imagem jamais podem ser zero porque isto é proibido pelo padrão implementado. Portanto, o segundo byte após o código de início de imagem indicado por OxYY na Figura 21 jamais pode ser 0x00. Assim, se a área de texto simples começa com 0x00 0x01 0x00, estes precisam ser os últimos três bytes do código de início de imagem. Se esta começa com 0x01 0x00, estes são os últimos dois bytes. Se esta começa com 0x00 mas não com 0x00 0x01 0x00, há somente o último byte. Deste modo, é sabido exatamente onde o código de início de imagem está localizado e os dados a seguir podem ser analisados. O tipo de imagem pode ser lido a partir do byte OxYY, se necessário.
Pode-se também dizer que é impossível limpar o último pacote de um quadro I removendo todos os dados não de quadro I, se o código de início de imagem é espalhado através de dois pacotes. Este é um fato correto, porque a parte criptografada do código de início de imagem não é removida. Porém na construção do fluxo de truncagem, um quadro P vazio será anexado ao final do quadro I. Este quadro P vazio começará com um código de início de imagem. Assim, os bytes criptografados do código de início de imagem podem ser reutilizados porque é sabido quantos destes bytes há no final do último pacote criptografado. Este número de bytes é removido do código de início de imagem do primeiro quadro P vazio a ser adicionado após o quadro I.
Figura 22 mostra um exemplo de tal situação e particularmente mostra um código de início de imagem 2200, uma referência temporal 2201, um tipo de codificação de imagem 2202 e dados de quadro vazio 2203.
Os dados de quadro P inseridos tem que ser tem texto simples, na ausência de um criptografador DVB no meio de armazenagem. As situações que devem ser esperadas na prática são descritas acima, mas na teoria algumas situações adicionais podem ocorrer. Isto se origina do fato que a área de cabeçalho PES de texto simples e a área de texto simples resultante dos critérios 2 e 3, na teoria não precisa estar conectada mas pode estar separada por pacotes de vídeo criptografados. Para clareza, é mencionado que uma área de texto simples contígua significa que uma seqüência de pacotes de vídeo está em texto simples, mas que outros pacotes criptografados podem estar entre eles.
Alinhadas com os critérios, há três áreas de dados importantes que podem ter que ser acessadas:
1. A informação de cabeçalho PES.
2. A informação de cabeçalho de seqüência e extensão de
seqüência.
3. A informação do código de início de imagem para a extensão de codificação de imagem.
Estas três áreas de dados são mostradas na Figura 23.
Figura 23 mostra áreas de dados de texto simples correspondentes aos três pontos acima mencionados. Com relação ao primeiro ponto, um PLUSI 2300 (indicador de início de unidade de carga útil) e um cabeçalho PES 2301 são mostrados.
De acordo com o segundo ponto, uma extensão de seqüência 2302, um código de extensão de seqüência 2302, um cabeçalho de seqüência 2304 e um código de cabeçalho de seqüência 2305 são mostrados, bem como um código de início de imagem 2306.
Referindo-se ao terceiro ponto, um código de início de imagem 2308 e um cabeçalho de imagem 2307 são mostrados, bem como o código de extensão de codificação de imagem 2309 e uma extensão de codificação de imagem 2310. Três itens deveriam ser encontrados no fluxo, no sentido de localizar e analisar corretamente estes dados:
1. O bit PLUSI 2300 no cabeçalho de pacote.
2. O código de cabeçalho de seqüência 2305 (0x00 0x00 0x01 0xB3).
3. O código de início de imagem 2308 (0x00 0x00 0x01 0x00).
Encontrar o item 1 é fácil, uma vez que é suficiente apenas buscar o bit PLUSI 2300 no cabeçalho de pacote, e se este é ajustado para "1", o pacote começará com o cabeçalho PES 2301, que pode então ser analisado.
A situação para os itens 2 e 3 pode ser mais complicada, porque o código de cabeçalho de seqüência 2305 e código de início de imagem 2308 podem ser espalhados através de dois pacotes, resultando em códigos parcialmente criptografados. Portanto, uma detecção direta destes códigos conduziria a alguma perda de dados. Há, entretanto, uma solução para este problema. No MPEG2, a presença da extensão de seqüência 2030 e extensão de seqüência de imagem 2301 é mandatório, como é mostrado na Figura 24.
Figura 24 mostra um cabeçalho de seqüência 2304 acoplado à extensão de seqüência 2302, que são providos a dados de extensão de usuário 2400. Adicionalmente, dados de extensão de usuário 2400 são acoplados a um grupo de cabeçalho de imagens 2401 que é acoplado a dados de usuário 2402. Os dados de usuário 2402 são acoplados a um cabeçalho de imagem 2307 que é acoplado a uma extensão de codificação de imagem 2310. Esta extensão de codificação de imagem 2310 é acoplada ao dados de usuário 2403, e os dados de usuário 2403 são acoplados a dados de imagem 2404. Então, um final de seqüência 2405 é alcançado.
O modo pelo qual os critérios para pacotes de texto simples são formulados, garante que estas três extensões serão plenamente em texto simples. Estas podem ser encontradas buscando primeiramente o código de início de extensão sendo OxOO 0x00 0x01 0xB5. Os próximos quatro bits são o identificador de código de início de extensão. Estes quatro bits são 0x01 para a extensão de seqüência e 1000 para a extensão de codificação de imagem. Se uma extensão de seqüência está presente, o código de cabeçalho de seqüência precisa também estar presente e identicamente se uma extensão de codificação de imagem está presente, o código de início de imagem precisa também estar presente. Isto conduz ao seguinte:
Se uma extensão de seqüência 2302 é encontrada em uma área de texto simples e o cabeçalho de seqüência 2304 não é detectado nesta mesma área, então o cabeçalho de seqüência 2304 precisa ser espalhado através de dois pacotes, e o(s) último(s) byte(s) do cabeçalho de seqüência 2304 são os primeiros bytes desta área de texto simples, desprezando um possível cabeçalho PES (ver Figura 25).
Se uma extensão de codificação de imagem 2310 é encontrada em uma área de texto simples e o código de início de imagem 2308 não é detectado nesta mesma área, então o código de início de imagem 2308 precisa ser espalhado através de dois pacotes, e o(s) último(s) byte(s) do código de início de imagem 2308 são os primeiros bytes desta área de texto simples, desprezando um possível cabeçalho PES (ver Figura 26).
Deveria ser notado que estas duas situações jamais podem ocorrer simultaneamente em uma área de texto simples. Se a extensão de seqüência 2302 e extensão de codificação de imagem 2310 estão ambas presentes, o código de início de imagem 2308 que está localizado entre estas duas inevitavelmente será todo em texto simples. Somente o código de cabeçalho de seqüência 2305 pode ser parcialmente criptografado neste caso. Naturalmente, se um código de cabeçalho de seqüência 2305 ou código de início de imagem 2308 é inteiramente em texto simples e portanto, detectado de uma maneira direta, a análise dos dados correspondente pode começar imediatamente. Entretanto, se uma das situações acima é encontrada, é preciso inicialmente ser conhecido quantos bytes destes códigos estão no início da área de texto simples ou após o cabeçalho PES, antes que uma análise correta possa começar. O método para detectar isto para o código de início de imagem 2308 foi descrito anteriormente. O mesmo método pode também ser aplicado para o código de cabeçalho de seqüência 2305.
A situação para o código de cabeçalho de seqüência 2305 é exibida na Figura 27.
O texto simples é somente garantido a partir do quarto byte para diante. Este byte é o último byte do código de cabeçalho de seqüência 2305 que é igual a 0x00 0x00 0x01 0xB3. Assim, se um código de cabeçalho de seqüência 2305 está presente mas não detectado nesta área, alguns de seus últimos bytes precisam estar presentes no início desta área ou após o cabeçalho PES. Como com o código de início de imagem 2308, é possível detectar exatamente quantos destes bytes há. A detecção começará no primeiro byte de texto simples na área, desprezando o cabeçalho PES. Se os primeiros bytes são 0x00 0x01 0xB3, há três bytes, se estes são 0x01 0xB3, há dois bytes e se o primeiro byte é 0xB3, há somente este byte. Conhecer o número de bytes e portanto, a localização do último byte do código de cabeçalho de seqüência 2305 ou código de início de imagem 2308, habilita uma análise correta dos dados em seguida a este código.
A seguir, a construção do fluxo no nível de fluxo de transporte será explicada.
Neste contexto, o posicionamento de pacote será primeiramente descrito.
A posição dos pacotes copiados para o fluxo de truncagem pode usualmente não ser acoplada à temporização relativa do fluxo de transporte original, devido à compressão e possível inversão (modo reverso) do eixo dos tempos na truncagem. Portanto, as marcações de tempo de chegada de pacotes pré pendentes do fluxo de transporte com marcação de tempo de chegada de pacote original usualmente não são utilizáveis para geração de truncagem. Esta é uma razão pela qual o método de truncagem descrito pode também ser usado para fluxos de transporte, sem marcações de tempo de chegada de pacotes pré pendentes. Como a temporização relativa original não é usada, um outro mecanismo de temporização tem que ser escolhido. Como se tornará claro mais tarde, um meio adequado de fazer isto é suavizar a taxa de pacote através de um GOP de truncagem, como é mostrado na Figura 28.
Figura 28 ilustra esquematicamente a suavização de pacote para truncagem.
Como pode ser visto, um fluxo de radiodifusão 2800 inclui dados de quadro I 2801, dados de quadro P/B 2802 e dados de quadro I adicionais 2803. Os dados de quadro I 2801 não são providos equidistantemente, mas compreendem diversos pacotes distribuídos de uma maneira não ordenada no domínio do tempo, como pode ser visto na linha superior 2800 na Figura 28.
O formato de dados conforme armazenado no disco rígido é mostrado na linha 2810 da Figura 28. Aqui, os vários pacotes únicos dos dados de quadro I 2801 são providos um após o outro, sem uma distância entre eles, bem como os dados de quadro P/B 2802 e os dados de quadro I adicionais 2803.
Uma saída de truncagem 2820 é ilustrada na Figura 28, mostrando um pacote PCR 2824 (Referência de Relógio de Programa) seguido de pacotes PAT (Tabela de Associação de Programa) e PNT (Tabela de Mapa de Programa) 2825. Então, a seqüência de pacotes dos dados de quadro I 2801 é provida de uma maneira suavizada como dados de quadro I suavizados 2822 seguidos de dados de quadro P vazio suavizados 2823. Entretanto, quadros B vazios suavizados são também possível adicionalmente ou alternativamente. Subseqüentemente, um pacote PCR adicional 2824 e dois pacotes PAT, PNT 2825 são providos, seguidos por dados de quadro I adicionais suavizados 2826. Os dados de quadro I suavizados 2822 e dados de quadro P vazio suavizados 2823 são espaçados no domínio do tempo por um tempo GOP nominal T/R 2821.
O número de pacotes para o quadro I 2822 é conhecido, pois é para os quadros P vazios 2823 e alguns pacotes adicionais (por exemplo, PCR, ECM, SIT, DIT, etc.). O total dos pacotes é transmitido no tempo GOP nominal T/R 2821 que é igual a IZRt ou T/R. A distância de pacote é calculada a partir do número de pacotes e tempo GOP nominal T/R 2821. De fato, o momento de transmissão do pacote calculado pode ser traduzido em novas marcações de tempo de chegada de pacote que são pré pendentes para os pacotes de truncagem. Estas marcações de tempo de chegada de pacote podem ser derivadas do valor calculado da nova base de tempo de truncagem PCR no início do pacote. Deste modo, o fluxo de truncagem gerado 2820 pode ser processado pelos mesmos circuitos de saída que podem ser usados para reprodução normal. A nova base de tempo de truncagem PCR será discutida posteriormente.
A seguir, aspectos relacionados a Referência de Relógio de Programa (PCR) serão descritos.
A base de tempo PCR original pode usualmente não ser usada para truncagem. Antes de tudo é provável mas não garantido que uma PCR estará presente dentro do quadro I selecionado. De forma mais importante, a freqüência da base de tempo PCR não é mais correta. Esta freqüência deveria estar dentro de 30 ppm a partir de 27 MHz, mas é agora multiplicada pelo fator de velocidade de truncagem, conduzindo o mesmo a uma base de tempo executada na direção errada para truncagem reversa.
Então, a base de tempo PCR antiga tem que ser removida e uma nova tem que ser adicionada. As PCR antigas são removidas limpando os campos de adaptação nos quais estão localizadas. Os campos de adaptação não são criptografados. As novas PCR são adicionadas colocando um pacote PCR adicional 2824 no começo de cada GOP de truncagem 2821, conforme indicado na Figura 28. Uma vez que estes GOP são transmitidos exatamente no tempo GOP nominal T/R 2821, a distância entre valores PCR é constante e pode ser derivada deste tempo GOP nominal T/R 2821. Como resultado, a adição de uma nova base de tempo PCR com alta precisão de temporização é muito simples.
A PCR 2824 é composta de duas partes, a saber base PCR e extensão PCR. A última é a parte LSB de 9 bits que pode variar de O a 299. A base PCR é a parte MSB com um tamanho de 33 bits e um alcance pleno. A freqüência da base PCR é 27 MHz/300 = 90 kHz. Quase todas as taxas de quadro se ajustam a estes 90 kHz. Para estas taxas, a extensão PCR é constante para pontos que são um múltiplo inteiro do tempo de quadro separado. Como o tempo GOP nominal T/R 2821 é tal múltiplo inteiro, a extensão PCR de todas as PCR inseridas da nova base de tempo podem ser ajustadas para zero. Somente as taxas excêntricas de 23,976 Hz e 59,94 Hz não se ajustam aos 90 kHz. Entretanto, para 59,94 Hz, a extensão PCR é constante para uma distância igual a um múltiplo par do tempo de quadro, e no caso de 23,976 Hz para um tempo de quadro quádruplo. Com a estrutura GOP de truncagem IPPP (T=4), um valor fixo de zero para a extensão PCR pode ser usado para todas as taxas de quadro, simplificando adicionalmente a inserção de uma nova base de tempo PCR .
A distância entre as PCR subseqüentes 2824 no fluxo transmitido, de acordo com o padrão MPEG2, não deveria exceder 100 ms. No padrão DVB, este valor é mesmo baixo, a saber 40 ms. Enviando somente uma PCR 2824, cada GOP de truncagem 2821 viola claramente estes limites. Em uma situação de pior caso com T=4 e R=25 Hz, a distância entre as PCR 2824 é de 160 ms. Nas experiências, não foram verificados problemas com a violação desta distância. As PCR adicionais 2824 poderiam ser incluídas no fluxo, porém isto é mais complexo e não parece ser necessário em todos os casos.
A seguir, aspectos relacionados a Marcação de Tempo de Decodificação (DTS) e Marcação de Tempo de Apresentação (PTS) serão discutidos.
Quadros podem conter duas marcações de tempo, que podem informar a um decodificador quando iniciar a decodificação do quadro (DTS) e quando iniciar a apresentação (por exemplo, visualização) (PTS). Estes são iniciados quando DTS, respectivamente PTS, são iguais à base de tempo PCR, que é reconstruída no decodificador por meio das PCR no fluxo. Uma vez que uma nova base de tempo PCR é adicionada ao fluxo de truncagem e como as distâncias no tempo para DTS e PTS não são mais corretas de modo algum, DTS e PTS do quadro I podem ser substituídas, se presentes. DTS e PTS estão localizadas no cabeçalho PES.
Existem pelo menos duas maneiras para construir um GOP de truncagem, a saber com um pacote PES por quadro ou um por GOP. No caso de um código de início de imagem parcialmente criptografado, um pacote PES por quadro pode de fato não ser usado. Assim, um pacote PES por GOP pode ser escolhido, mesmo se o fluxo original era de um pacote PES por quadro. Portanto, os quadros P vazios inseridos não possuem DTS ou PTS. A extensão de pacote PES é ajustada para zero (não limitada) qualquer que seja seu valor original.
Deveria ser considerado quando a decodificação do quadro I puder começar. Os pacotes do GOP de truncagem são espalhados através do tempo GOP constante. Quase todo o GOP de truncagem é relacionado a dados de quadro I, assim o final do quadro I está próximo do início do próximo GOP. Portanto, a decodificação do quadro I pode começar no início do próximo GOP. Assim, a DTS do quadro I é ajustada para um valor correspondente à base de tempo PCR no início do próximo GOP. A DTS e PTS usualmente contém somente uma referência à base PCR. A DTS é portanto, idêntica à base PCR que será inserida no início do próximo GOP.
Deveria ser adicionalmente considerado quando a apresentação do quadro I pudesse começar. Um tempo de um quadro entre DTS e PTS não só é apropriado para um fluxo somente com quadros I e quadros P, porém é o que o padrão MPEG2 prescreve para tal fluxo, se low_delay Jlag não é ajustado. Assim, a PTS do quadro I é ajustada para o valor DTS mais um valor correspondente a um tempo de quadro. Para as taxas de quadro de 23,976 Hz e 59,94 Hz, este é um valor próximo de um tempo de quadro. A distância PCR entre o início dos GOP de truncagem sucessivos já é calculada. Esta distância tem uma precisão igual à base PCR e portanto, igual a DTS e PTS. O valor de desvio entre PTS e DTS pode ser calculado dividindo a distância PCR pelo tamanho GOP de truncagem T. isto de fato é muito simples no caso de uma estrutura IPPP (T=4) onde é necessário dividir por 4. Os bits da distância PCR são simplesmente deslocados de dois lugares para calcular o desvio PTS/DTS. Isto é exibido na Figura 29.
Figura 29 mostra um diagrama 2900 onde o tempo t é lançado ao longo de uma abscissa 2901 e a base PCR é lançada ao longo de uma ordenada 2902. Figura 29 relaciona-se a um tamanho de GOP de T=4 e uma Taxa de Atualização de R=25.
A seguir, alguns aspectos relacionados à inserção das Mensagens de Controle de Intitulação (ECM) serão discutidos.
No caso de um fluxo de truncagem criptografado, as ECM tem que estar presentes neste fluxo, para habilitar a descriptografia pelo receptor (por exemplo, um STB). Neste contexto, deveria ser decidido quando as ECM tem que ser inseridas e onde. Em um caso preferido, onde o fluxo gravado já contém os pacotes de texto simples necessários, o bloco de dados híbrido a partir do dispositivo de armazenagem conterá somente dados de quadro I. O método de inserção ECM entretanto, deveria também permitir o caso mais geral com tamanhos de blocos maiores.
O primeiro quadro I do bloco de dados é usado para construir um GOP de truncagem. A maioria das ECM terá que ser enviada a algum lugar entre estes quadros I, que está de fato entre dois GOP de truncagem. Conforme descrito previamente, todos os GOP de truncagem podem ter uma extensão igual no tempo e os pacotes de um GOP podem ser espalhados através deste tempo para suavizar a taxa de bit. Inserir as ECM entre estes GOP aumentaria desnecessariamente a taxa de bit local. Pode ser melhor embutir a ECM em um GOP de truncagem. Então, tem que ser decidido a qual GOP a ECM é adicionada. Há particularmente as seguintes duas opções:
1. Uma ECM pode ser adicionada no final do GOP de truncagem prévio.
2. Uma ECM pode ser adicionada ao começo do próximo GOP de truncagem.
Na segunda opção, a ECM não é realmente o primeiro pacote do próximo GOP, porque estas são as PCR inseridas que precisam permanecer naquela posição por razões de temporização. Assim, a ECM é o segundo pacote neste caso. Embora na prática a diferença entre as duas opções possa ser desprezível em muitos casos, a posição ótima é dada pela opção 1 porque maximiza o tempo disponível para a descriptografia da ECM.
Esta situação é mostrada na Figura 30.
Figura 30 mostra, em adição a componentes já introduzidos, um comutador SCB 3000, um pacote ECM 3001 e dados de quadro I 3002. Ainda mais, quadros P vazios 3003 são ilustrados na Figura 30.
Com truncagem para diante, pode também ocorrer algumas vezes que o comutador SCB 3000 não esteja localizado entre os quadros I, mas em algum lugar dentro do quadro I selecionado. Uma ECM 3001 tem que ser enviada quando o comutador SCB 3000 é cruzado. Isto significa que neste caso a ECM 3001 deveria ser inserida na localização correta dentro do quadro I. Novamente, há em particular duas opções para fazer isto:
1. ECM 3001 pode ser inserida antes do pacote de quadro I com o comutador SCB 3000.
2. ECM 3001 pode ser inserida após o pacote de quadro I com o comutador SCB 3000.
O pacote com o comutador SCB 3000 é o pacote de vídeo criptografado com um valor SCB diferente do pacote de vídeo criptografado precedente. Em alguns casos, realmente não importa se a opção 1 ou 2 é usada, mas na teoria a melhor posição é usualmente antes do pacote com o comutador SCB 3000. Isto é porque, por um lado, a CW do período prévio não é mais necessária a partir deste momento, e, por outro lado, o tempo para descriptografar a ECM 3001 é maximizado.
A opção 1 é exibida na Figura 31. Particularmente, um pacote 3100 com comutador SCB é mostrado na Figura 31.
Em todos os casos, o número PID e ID de tabela das ECM inseridas são preferivelmente os originais, para habilitar uma comutação suave entre a reprodução normal e a truncagem em ambas direções. O contador de continuidade no cabeçalho de pacote ECM pode ser corrigido então.
A seguir, alguns aspectos serão discutidos de onde fazer ou gerar o sistema híbrido.
O sistema híbrido descrito aqui pode ser criado em vários lugares. Neste contexto, é feita referência à Figura 32.
Os locais possíveis são de fato as mesmas localizações que para um fluxo com quadros I de texto simples (ver Figura 14 e descrição correspondente):
1'. No radiodifusor 1401 ou enlace ascendente no caso de radiodifusão via satélite. 2'. Na extremidade de cabo principal 1405 no caso de uma rede de cabo.
3'. No ponto de conexão residencial 1407 no caso de um domínio autorizado seguro.
4'. No lado de gravação do dispositivo de armazenagem 1409. Entretanto, para um fluxo somente com uns poucos pacotes de texto simples, uma quinta localização deveria ser adicionada:
5'. No lado de reprodução do dispositivo de armazenagem 1406, 1408, 1409.
As localizações possíveis 1' a 5' são visualizadas na Figura 32. As localizações 1' e 2' podem ser difíceis de realizar porque há somente uma influência limitada aqui. Para o dispositivo de armazenagem, de fato na faz diferença se a transformação para um fluxo híbrido é realizada nas localizações 1', 2' ou 3'. Assim, a opção 3' pode ser uma escolha muito boa. Em todos os três casos, o dispositivo de armazenagem pode receber um fluxo híbrido em sua entrada de gravação. Isto significa que nenhuma descriptografia e cartão inteligente são necessários no dispositivo de armazenagem, pelo menos não para reprodução normal e geração de truncagem. Porém a descriptografia pode ainda ser necessária se uma função de extração de metadados estiver presente dentro do dispositivo de armazenagem que usa a detecção de quadros de código, etc. Uma localização apropriada para construir o fluxo híbrido pode ser o caso 4', que está no lado de gravação do dispositivo de armazenagem. Embora isto solicite uma descriptografia parcial no lado de gravação, ainda tem a vantagem de que nenhuma descriptografia é necessária para a geração de truncagem. De qualquer modo, é preferível que o fluxo gravado seja híbrido. No caso 5', onde a gravação é feita com todos os pacotes criptografados, é ainda possível criar truncagem seguro conforme descrito aqui. Na Figura 16, a abordagem básica para trabalhar com um fluxo plenamente criptografado foi mostrada. Mas ao invés de uma descriptografia plena, é possível descriptografar somente aqueles pacotes necessários, e deixar o restante ainda criptografado (ver Figura 33).
Figura 33 mostra um sistema 3310 que difere do sistema 1600 pelo fato de que o descriptografador 1603 emite dados MPEG2 parcialmente descriptografados 3300 e que o decodificador MPEG2 1506 é substituído por um decodificador MPEG2 e descriptografador 3302 que recebe um fluxo de transporte conforme a MPEG2 parcialmente descriptografado 3501. É ainda possível criar um fluxo de truncagem predominantemente criptografado.
A seguir, referindo-se à Figura 34A e Figura 34B, um dispositivo 3400 para processar um fluxo de dados criptografado 3401 de acordo com uma realização típica da invenção será descrito.
Particularmente, a Figura 34A ilustra um diagrama em blocos de geração de fluxo híbrido do dispositivo 3400. Figura 34B ilustra um diagrama em blocos de geração de fluxo de truncagem, que pode ser usado juntamente com o diagrama em blocos de geração de fluxo híbrido da Figura 34A do dispositivo 3400.
O dispositivo 3400 compreende uma unidade de descriptografia 3402 que gera um fluxo de dados descriptografado 3403 a partir do fluxo de dados criptografados 3401.
Adicionalmente, o dispositivo 3400 inclui uma unidade de detecção 3404 que está detectando informação de posição de quadros I no fluxo de dados descriptografado 3403. Particularmente, a unidade de detecção 3404 detecta, como a informação de posição, uma posição inicial e uma posição final de cada um dos quadros I incluídos no fluxo de dados descriptografado 3403.
Ainda mais, o dispositivo 3400 inclui uma unidade de substituição 3405 que substitui, com base na informação de posição detectada pela unidade de detecção 3404, porções do fluxo de dados criptografados 3401 providas em uma primeira entrada da unidade de substituição 3405 por porções correspondente do fluxo de dados descriptografado 3403 provido em uma segunda entrada da unidade de substituição 3405. Em outras palavras, a unidade de substituição 3405 substitui porções do fluxo de dados criptografados 3401 por porções correspondentes do fluxo de dados descriptografado 3403 na posição inicial detectada e posição final dos quadros I. Conseqüentemente, um fluxo de dados híbridos 3407 é gerado em uma saída da unidade de substituição 3405 do diagrama em blocos de geração de fluxo híbrido da Figura 34A.
O fluxo de dados híbridos 3407 provido em uma saída do sistema da Figura 34A pode ser conectado a uma entrada do sistema da Figura 34B. Entretanto, a armazenagem dos dados híbridos pode ser envolvida opcionalmente.
A unidade de gerador de truncagem da Figura 34B pode opcionalmente incluir uma (adicional) unidade de detecção 3404.
O fluxo de dados híbridos 3407 pode ser suprido a uma unidade de geração de truncagem 3408 para gerar um fluxo de dados 3409 para reprodução em um modo de reprodução de truncagem, e pode ser suprido à unidade de detecção adicional 3404. Adicionalmente, uma unidade de adição 3406 é mostrada, a qual é provida com uma saída da unidade de detecção adicional 3404. A unidade de adição 3406 pode adicionar informação de temporização ao fluxo de dados. Os dados adicionados pela unidade de adição 3406 estão em texto simples. Uma saída da unidade de adição pode ser provida à unidade de geração de truncagem 3408.
A unidade de geração de truncagem 3408 gera, com base em suas entradas, o fluxo de dados 3409 para reprodução em um modo de reprodução de truncagem.
Este fluxo de truncagem 3409 é provido a uma unidade de reprodução 3410. A unidade de adição 3406 pode também adicionar tabelas, dados ECM e/ou quadros vazios.
A unidade de geração de truncagem 3408 pode cuidar de remultiplexação, problemas de temporização, suavização de pacotes remultiplexados e/ou limpeza de pacotes de quadro.
A(s) unidade(s) de detecção 3404 pode(m) detectar limites de quadro dentro do fluxo descriptografado 3403 ou fluxo híbrido 3407. Tais limites de quadro podem ser limites de quadros I, quadros B e/ou quadros P.
A situação da Figura 3 4A, Figura 34B é adicionalmente descrita referindo-se à Figura 35, mostrando diferentes fluxo de dados.
Na Figura 35, o fluxo de dados criptografado 3401 é mostrado. Após ter passado a unidade de descriptografia 3402, o fluxo de dados completamente descriptografado 3403 é gerado. A Figura 35 ilustra adicionalmente posições iniciais 3500 e posições finais 3501 detectadas dentro do fluxo de dados descriptografado 3403 detectado pela unidade de detecção adicional 3404. Após ter passado a unidade de substituição 3405, porções relacionadas a posições iniciais 3500 e a posições finais 3501 do fluxo de dados criptografados 3401 são substituídas por porções descriptografia 3502. A unidade de adição 3406 adiciona informação de temporização 3503 em um início do fluxo.
Ainda mais, conforme mostrado na Figura 35, informação Mensagens de Controle de Intitulação (ECM) pode ser adicionada em uma posição final do fluxo de dados que é denotada pelo numerai de referência 3504.
E notado que, adicionalmente ou alternativamente, para a detecção de limites de quadro I, é também possível detectar limites (isto é, posições de início e/ou fim) de quadros B e/ou quadros P.
A seguir, referindo-se à Figura 36, um dispositivo 3600 para processar um fluxo de dados 3601 possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes de acordo com uma outra realização típica da invenção, será descrita.
O dispositivo 3600 compreende uma unidade de distribuição 3602 para distribuir uniformemente ou homogeneamente os pacotes através do fluxo de dados 3601. Esta unidade de distribuição 3602 que pode também ser denotada como uma unidade suavizadora gera porções arranjada equidistantemente de quadros I, conforme mostrado na terceira linha da Figura 28.
Uma unidade de substituição 3603 substitui a informação de temporização do fluxo de dados que não é mais válida, por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
Adicionalmente, uma unidade de inserção de informação de descriptografia 3604 é provida, a qual insere Mensagens de Controle de Intitulação (ECM) como informação de descriptografia no fluxo de dados.
Ainda mais, uma unidade de geração de truncagem 3605 é provida, a qual gera um fluxo de dados para reprodução em um modo de reprodução de truncagem. Dados de truncagem 3607 são providos a uma unidade de reprodução 3606 para reprodução.
E notado que o arranjo dos componentes da Figura 36 pode ser modificado. Por exemplo, as posições da unidade de substituição 3603 e da unidade de distribuição 3602 podem ser trocadas.
A seguir, será descrito o caminho de fluxo de sinal da Figura 36.
A unidade de geração de truncagem 3605 é provida do fluxo de dados 3601. Uma saída da unidade de geração de truncagem 3605 é acoplada a uma entrada da unidade de inserção de informação de descriptografia 3604. Uma saída da unidade de inserção de informação de descriptografia 3604 é acoplada a uma entrada da unidade de substituição 3603. Uma saída da unidade de substituição 3603 é acoplada a uma entrada da unidade de distribuição 3602. Uma saída da unidade de distribuição 3602 (na qual os dados de truncagem 3607 são providos) é acoplada a uma entrada da unidade de reprodução 3606.
Deveria ser notado que o termo "compreendendo" não exclui outros elementos ou etapas e o "um" ou "uma" não exclui diversos. Também elementos descritos em associação com diferentes realizações podem ser combinados.
Deveria também ser notado que sinais de referência nas reivindicações não serão considerados como limitando o escopo das reivindicações.
Claims (36)
1. Dispositivo (3400) para processar um fluxo de dados criptografado (3401), caracterizado pelo fato de que o dispositivo (3400) compreende unidade de descriptografia (3402) para gerar um fluxo de dados descriptografado (3403) a partir do fluxo de dados criptografado (3401); unidade de detecção (3404) para detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografado (3403); unidade de substituição (3405) para substituir, com base na informação de posição detectada, porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403).
2. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de que a unidade de detecção (3404) é adaptada para detectar informação de posição de pelo menos um quadro preditivo de avanço e/ou de pelo menos um quadro preditivo bidirecional no fluxo de dados descriptografado (3403).
3. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de ser adaptado para gravar um fluxo híbrido.
4. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de que a unidade de detecção (3402) é adaptada para detectar, como informação de posição, uma posição inicial (3500) e uma posição final (3501) de pelo menos um quadro intra-codificado no fluxo de dados descriptografado (3403).
5. Dispositivo (3400) de acordo com a reivindicação 4, caracterizado pelo fato de que a unidade de substituição (3405) é adaptada para substituir porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403) na posição inicial detectada (3500) e posição final (3501) de pelo menos um quadro intra- codificado.
6. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de compreender uma unidade de adição (3406) adaptada para adicionar informação de temporização a um fluxo de dados que já tenha sido processado antes pela unidade de substituição (3405), a informação de temporização incluindo uma referência a uma posição de pelo menos um quadro intra-codiflcado.
7. Dispositivo (3400) de acordo com a reivindicação 6, caracterizado pelo fato de que a unidade de adição (3406) é adaptada para adicionar a informação de temporização em texto simples.
8. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de que a unidade de substituição (3405) é adaptada para substituir uma quantidade de dados do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403), cuja quantidade é minimamente requerida para gerar um fluxo de dados (3409) para reprodução em um modo de reprodução de truncagem.
9. Dispositivo (3400) de acordo com a reivindicação 4, caracterizado pelo fato de que a unidade de substituição (3405) é adaptada de tal maneira que os dados entre uma posição inicial (3500) e uma posição final (3501) do pelo menos um quadro intra-codificado estão livres de serem substituídos por porções correspondentes do fluxo de dados descriptografado (3403).
10. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de que a unidade de substituição (3405) é adaptada para substituir um indicador de extensão de pacote de fluxo elementar empacotado, uma marcação de tempo de apresentação e/ou uma marcação de tempo de decodificação em uma unidade de cabeçalho do fluxo de dados criptografado (3401).
11. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de ser adaptado para processar um fluxo de dados criptografado (3401) de dados de vídeo ou dados de áudio.
12. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de ser adaptado para processar um fluxo de dados criptografado (3401) de dados digitais.
13. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de compreender uma unidade de geração de truncagem (3408) adaptada para gerar um fluxo de dados (3409) para reprodução em um modo de reprodução de truncagem baseado em uma saída da unidade de substituição (3405).
14. Dispositivo (3400) de acordo com a reivindicação 13, caracterizado pelo fato de que o modo de reprodução de truncagem é um do grupo consistindo de um modo de reprodução de avanço rápido, um modo de reprodução de retorno rápido, um modo de reprodução de movimento lento, um modo de reprodução de quadro congelado, um modo de reprodução de repetição instantânea, e um modo de reprodução reversa.
15. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de ser adaptado para processar o fluxo de dados MPEG2 criptografado.
16. Dispositivo (3400) de acordo com a reivindicação 1, caracterizado pelo fato de ser realizado em pelo menos um do grupo consistindo de um dispositivo de gravação de vídeo digital e um dispositivo habilitado pela rede e um sistema de acesso condicional e um reprodutor de áudio portátil e um reprodutor de vídeo portátil e um telefone móvel e um reprodutor de DVD e um reprodutor de CD, um reprodutor de mídia baseado em disco rígido e um dispositivo de rádio Internet e um dispositivo de entretenimento público e um reprodutor de MP3.
17. Método para processar um fluxo de dados criptografado (3401) caracterizado pelo fato de compreender as etapas de gerar um fluxo de dados descriptografado (3403) a partir do fluxo de dados criptografado (3401), detectar informação de posição de pelo menos um quadro intra- codificado no fluxo de dados descriptografado (3401) substituindo, com base na informação de posição detectada, porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403).
18. Meio legível por computador, caracterizado pelo fato de que um programa de computador para processar um fluxo de dados criptografado (3401) é armazenado no mesmo, cujo programa de computador, ao ser executado por um processador, é adaptado para controlar ou executar as seguintes etapas de método: gerar um fluxo de dados descriptografado (3403) a partir do fluxo de dados criptografado (3401); detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografado (3403); substituir, com base na informação de posição detectada, porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403).
19. Elemento de programa para processar um fluxo de dados criptografado (3401), caracterizado pelo fato de que o elemento de programa, ao ser executado por um processador, é adaptado para controlar ou executar as etapas de método de: gerar um fluxo de dados descriptografado (3403) a partir do fluxo de dados criptografado (3401); detectar informação de posição de pelo menos um quadro intra-codificado no fluxo de dados descriptografado (3403); substituir, com base na informação de posição detectada, porções do fluxo de dados criptografado (3401) por porções correspondentes do fluxo de dados descriptografado (3403).
20. Dispositivo (3600) para processar um fluxo de dados (3601) possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, caracterizado pelo fato do dispositivo (3600) compreender unidade de distribuição (3602) para distribuir uniformemente os pacotes através do fluxo de dados (3601); unidade de substituição (3603) para substituir a informação de temporização do fluxo de dados (3601) por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
21. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de que a unidade de distribuição (3602) é adaptada para distribuir uniformemente pacotes relacionados a uma porção do fluxo de dados (3601) entre dois quadros intra-codificados subseqüentes.
22. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de que a unidade de substituição (3603) é adaptada para arranjar a informação de temporização modificada em uma posição de início do fluxo de dados processados.
23. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de que a unidade de substituição (3603) é adaptada para gerar uma Referência de Relógio de Programa, uma Marcação de Tempo de Decodificação e/ou uma Marcação de Tempo de Apresentação como a informação de temporização modificada.
24. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de ser adaptado para processar o fluxo de dados criptografado (3601), onde o dispositivo (3600) compreende uma unidade de inserção de informação de descriptografia (3604) adaptada para inserir informação de descriptografia no fluxo de dados processados.
25. Dispositivo (3600) de acordo com a reivindicação 24, caracterizado pelo fato de que a unidade de inserção de informação de descriptografia (3604) é adaptada para inserir Mensagens de Controle de Intitulação como a informação de descriptografia.
26. Dispositivo (3600) de acordo com a reivindicação 24, caracterizado pelo fato de que a unidade de inserção de informação de descriptografia (3604) é adaptada para inserir a informação de descriptografia ao final do fluxo de dados processados.
27. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de ser adaptado para processar um fluxo de dados (3601) de dados de vídeo ou dados de áudio.
28. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de ser adaptado para processar um fluxo de dados (3601) de dados digitais.
29. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de compreender uma unidade de geração de truncagem (3605) adaptada para gerar um fluxo de dados (3607) para reprodução em um modo de reprodução de truncagem.
30. Dispositivo (3600) de acordo com a reivindicação 29, caracterizado pelo fato de ser adaptado para gerar o fluxo de dados (3607) para reprodução no modo de reprodução de truncagem, de tal maneira que diferentes Grupos de Imagens do fluxo de dados gerado possuem uma extensão essencialmente constante no tempo.
31. Dispositivo (3600) de acordo com a reivindicação 29, caracterizado pelo fato de que o modo de reprodução de truncagem é um do grupo consistindo de um modo de reprodução de avanço rápido, um modo de reprodução de retorno rápido, um modo de reprodução de movimento lento, um modo de reprodução de quadro congelado, um modo de reprodução de repetição instantânea, e um modo de reprodução reversa.
32. Dispositivo (3600) de acordo com a reivindicação 29, caracterizado pelo fato de ser adaptado para processar o fluxo de dados MPEG2 criptografado.
33. Dispositivo (3600) de acordo com a reivindicação 20, caracterizado pelo fato de ser realizado como pelo menos um do grupo consistindo de um dispositivo de gravação de vídeo digital e um dispositivo habilitado pela rede e um sistema de acesso condicional e um reprodutor de áudio portátil e um reprodutor de vídeo portátil e um telefone móvel e um reprodutor de DVD e um reprodutor de CD, um reprodutor de mídia baseado em disco rígido e um dispositivo de rádio Internet e um dispositivo de entretenimento público e um reprodutor de MP3.
34. Método para processar um fluxo de dados (3601) possuindo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, caracterizado pelo fato de que compreende as etapas de distribuir uniformemente os pacotes através do fluxo de dados (3601); substituir a informação de temporização do fluxo de dados (3601) por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
35. Meio legível por computador, caracterizado pelo fato de que um programa de computador para processar um fluxo de dados (3601), tendo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, é armazenado no mesmo, cujo programa de computador, ao ser executado por um processador, é adaptado para controlar ou executar as seguintes etapas de método: distribuir uniformemente os pacotes através do fluxo de dados (3601); substituir a informação de temporização do fluxo de dados (3601) por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
36. Elemento de programa para processar um fluxo de dados (3601) tendo uma seqüência de pacotes e informação de temporização relacionada aos pacotes, caracterizado pelo fato de que o elemento de programa, ao ser executado por um processador, é adaptado para controlar ou realizar as etapas do método de: distribuir uniformemente os pacotes através do fluxo de dados (3601); substituir a informação de temporização do fluxo de dados (3601) por informação de temporização modificada, ajustada para a distribuição uniforme dos pacotes.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP05103393 | 2005-04-26 | ||
| EP05103393.4 | 2005-04-26 | ||
| PCT/IB2006/051277 WO2006114759A2 (en) | 2005-04-26 | 2006-04-25 | A device for and a method of processing a data stream having a sequence of packets and timing information related to the packets |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0609561A2 true BRPI0609561A2 (pt) | 2011-10-18 |
Family
ID=37075854
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0609561-5A BRPI0609561A2 (pt) | 2005-04-26 | 2006-04-25 | dispositivo e método para processar um fluxo de dados, meio legìvel por computador, e, elemento de programa para processar um fluxo de dados |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US20080273698A1 (pt) |
| EP (1) | EP1878232A2 (pt) |
| JP (1) | JP2008539638A (pt) |
| KR (1) | KR20070122577A (pt) |
| CN (2) | CN101167357B (pt) |
| BR (1) | BRPI0609561A2 (pt) |
| MX (1) | MX2007013256A (pt) |
| RU (1) | RU2407214C2 (pt) |
| WO (1) | WO2006114759A2 (pt) |
Families Citing this family (69)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8966551B2 (en) * | 2007-11-01 | 2015-02-24 | Cisco Technology, Inc. | Locating points of interest using references to media frames within a packet flow |
| EP1854284B1 (en) * | 2005-03-02 | 2019-05-08 | Rohde & Schwarz GmbH & Co. KG | Apparatusand method for providing enhancements to atsc networks using synchronous vestigial sideband (vsb) frame slicing |
| US8340098B2 (en) * | 2005-12-07 | 2012-12-25 | General Instrument Corporation | Method and apparatus for delivering compressed video to subscriber terminals |
| WO2008036949A2 (en) * | 2006-09-22 | 2008-03-27 | Eg Technology. Inc. | Methods and systems for transport stream time base correction |
| EP2115911B1 (en) | 2007-02-01 | 2018-01-24 | Rohde & Schwarz GmbH & Co. KG | Improvement of synchronisation at the emission of atsc (advanced television systems committee) data packets |
| WO2009019739A1 (en) * | 2007-08-09 | 2009-02-12 | Thomson Licensing | A video data reproduction system |
| US10277956B2 (en) * | 2007-10-01 | 2019-04-30 | Cabot Communications | Method and apparatus for streaming digital media content and a communication system |
| JP5351039B2 (ja) | 2007-11-01 | 2013-11-27 | パナソニック株式会社 | 記録媒体、再生装置、記録装置、再生方法、及び記録方法 |
| KR101401967B1 (ko) * | 2007-12-04 | 2014-06-27 | 삼성전자주식회사 | 암호화된 데이터 스트림의 트릭 플레이 방법 및 장치 |
| DE102008017290A1 (de) | 2007-12-11 | 2009-06-18 | Rohde & Schwarz Gmbh & Co. Kg | Verfahren und Vorrichtung zur Bildung eines gemeinsamen Datenstroms insbesondere nach dem ATSC-Standard |
| DE102007059959B4 (de) * | 2007-12-12 | 2020-01-02 | Rohde & Schwarz Gmbh & Co. Kg | Verfahren und System zur Übertragung von Daten zwischen einer zentralen Rundfunkstation und mindestens einem Sender |
| JP2009177619A (ja) * | 2008-01-25 | 2009-08-06 | Panasonic Corp | 画像記録装置、画像再生装置、記録媒体、画像記録方法及びプログラム |
| US8700792B2 (en) | 2008-01-31 | 2014-04-15 | General Instrument Corporation | Method and apparatus for expediting delivery of programming content over a broadband network |
| WO2009116972A1 (en) * | 2008-03-20 | 2009-09-24 | Thomson Licensing | System and method for processing priority transport stream data in real time in a multi-channel broadcast multimedia system |
| DE102008056703A1 (de) | 2008-07-04 | 2010-01-07 | Rohde & Schwarz Gmbh & Co. Kg | Verfahren und System zur Zeitsynchronisierung zwischen einer Zentrale und mehreren Sendern |
| US8355458B2 (en) | 2008-06-25 | 2013-01-15 | Rohde & Schwarz Gmbh & Co. Kg | Apparatus, systems, methods and computer program products for producing a single frequency network for ATSC mobile / handheld services |
| US8752092B2 (en) | 2008-06-27 | 2014-06-10 | General Instrument Corporation | Method and apparatus for providing low resolution images in a broadcast system |
| US8739034B2 (en) * | 2008-08-13 | 2014-05-27 | Myine Electronics, LLC | Method and system for downloading and managing an edited media stream to a portable media device |
| DE102008059028B4 (de) * | 2008-10-02 | 2021-12-02 | Rohde & Schwarz GmbH & Co. Kommanditgesellschaft | Verfahren und Vorrichtung zur Erzeugung eines Transportdatenstroms mit Bilddaten |
| US8561105B2 (en) | 2008-11-04 | 2013-10-15 | Thomson Licensing | System and method for a schedule shift function in a multi-channel broadcast multimedia system |
| MX2011004645A (es) * | 2008-11-06 | 2011-05-30 | Rohde & Schwarz | Metodo y sistema para la asignacion sincronizada de paquetes de datos en un flujo de datos atsc. |
| EP2192773A1 (en) * | 2008-12-01 | 2010-06-02 | Irdeto Access B.V. | Content decryption device and encryption system using an additional key layer |
| JP5326602B2 (ja) * | 2009-01-23 | 2013-10-30 | 富士通株式会社 | サーバおよびコンテンツ配信方法 |
| EP2234357B1 (en) | 2009-03-21 | 2016-07-27 | Rohde & Schwarz GmbH & Co. KG | Method for improving the data rate of mobile data and the quality of channel estimation in an ATSC-M/H transport data stream |
| DE102009025219A1 (de) * | 2009-04-07 | 2010-10-14 | Rohde & Schwarz Gmbh & Co. Kg | Verfahren und Vorrichtung zur kontinuierlichen Anpassung von Kodierungsparametern an eine veränderliche Nutzdatenrate |
| DE102009057363B4 (de) * | 2009-10-16 | 2013-04-18 | Rohde & Schwarz Gmbh & Co. Kg | Verfahren und Vorrichtung zur effizienten Übertragung von überregional und regional auszustrahlenden Programm-und Servicedaten |
| NZ600198A (en) * | 2009-12-14 | 2014-02-28 | Sumitomo Electric Networks Inc | Content receiving device, content reproducing device, content receiving and reproducing device, content receiving method, and program |
| US9357244B2 (en) | 2010-03-11 | 2016-05-31 | Arris Enterprises, Inc. | Method and system for inhibiting audio-video synchronization delay |
| US20110271001A1 (en) * | 2010-04-30 | 2011-11-03 | Herve Brelay | Methods & apparatuses for a projected pvr experience |
| US8989021B2 (en) | 2011-01-20 | 2015-03-24 | Rohde & Schwarz Gmbh & Co. Kg | Universal broadband broadcasting |
| KR101803970B1 (ko) * | 2011-03-16 | 2017-12-28 | 삼성전자주식회사 | 컨텐트를 구성하는 장치 및 방법 |
| US8584167B2 (en) | 2011-05-31 | 2013-11-12 | Echostar Technologies L.L.C. | Electronic programming guides combining stored content information and content provider schedule information |
| US9699456B2 (en) * | 2011-07-20 | 2017-07-04 | Qualcomm Incorporated | Buffering prediction data in video coding |
| US8763027B2 (en) * | 2011-08-23 | 2014-06-24 | Echostar Technologies L.L.C. | Recording additional channels of a shared multi-channel transmitter |
| US8627349B2 (en) | 2011-08-23 | 2014-01-07 | Echostar Technologies L.L.C. | User interface |
| US8437622B2 (en) | 2011-08-23 | 2013-05-07 | Echostar Technologies L.L.C. | Altering presentation of received content based on use of closed captioning elements as reference locations |
| US9357159B2 (en) | 2011-08-23 | 2016-05-31 | Echostar Technologies L.L.C. | Grouping and presenting content |
| US9621946B2 (en) | 2011-08-23 | 2017-04-11 | Echostar Technologies L.L.C. | Frequency content sort |
| US9185331B2 (en) | 2011-08-23 | 2015-11-10 | Echostar Technologies L.L.C. | Storing multiple instances of content |
| US8447170B2 (en) | 2011-08-23 | 2013-05-21 | Echostar Technologies L.L.C. | Automatically recording supplemental content |
| US8660412B2 (en) | 2011-08-23 | 2014-02-25 | Echostar Technologies L.L.C. | System and method for dynamically adjusting recording parameters |
| US8959566B2 (en) | 2011-08-23 | 2015-02-17 | Echostar Technologies L.L.C. | Storing and reading multiplexed content |
| US9445095B1 (en) * | 2011-10-06 | 2016-09-13 | Arris Enterprises, Inc. | Compression of modified data captures for packets with encrypted or non-interesting content |
| US9066117B2 (en) * | 2012-02-08 | 2015-06-23 | Vixs Systems, Inc | Container agnostic encryption device and methods for use therewith |
| US8819722B2 (en) | 2012-03-15 | 2014-08-26 | Echostar Technologies L.L.C. | Smartcard encryption cycling |
| US8989562B2 (en) | 2012-03-15 | 2015-03-24 | Echostar Technologies L.L.C. | Facilitating concurrent recording of multiple television channels |
| US8959544B2 (en) | 2012-03-15 | 2015-02-17 | Echostar Technologies L.L.C. | Descrambling of multiple television channels |
| US9489981B2 (en) | 2012-03-15 | 2016-11-08 | Echostar Technologies L.L.C. | Successive initialization of television channel recording |
| US8793724B2 (en) | 2012-11-08 | 2014-07-29 | Eldon Technology Limited | Image domain compliance |
| US9762955B2 (en) | 2012-11-16 | 2017-09-12 | At&T Mobility Ii Llc | Substituting alternative media for presentation during variable speed operation |
| US9307021B2 (en) * | 2013-02-27 | 2016-04-05 | Comcast Cable Communications, Llc | Adaptive media transmission processing |
| US10552126B2 (en) * | 2013-03-15 | 2020-02-04 | Teradata Us, Inc. | Transitioning between code-based and data-based execution forms in computing systems and environments |
| US9998773B2 (en) * | 2013-06-07 | 2018-06-12 | Sony Corporation | Transmission device, transmission method of transmission stream, and processing device |
| RU2538943C1 (ru) * | 2013-07-19 | 2015-01-10 | Общество с ограниченной ответственностью "Завод Навигационного Оборудования" | Способ передачи данных от мобильного устройства на главную эвм с использованием протокола ascii |
| US9628838B2 (en) | 2013-10-01 | 2017-04-18 | Echostar Technologies L.L.C. | Satellite-based content targeting |
| WO2015052690A1 (en) * | 2013-10-10 | 2015-04-16 | Yandex Europe Ag | Methods and systems for indexing references to documents of a database and for locating documents in the database |
| CN103596043B (zh) * | 2013-11-14 | 2017-05-10 | 上海电力学院 | 一种数字电视中ts流转化为ps流的方法 |
| JP5741677B2 (ja) * | 2013-12-19 | 2015-07-01 | 株式会社ナカヨ | 通信装置および通信方法 |
| KR101551160B1 (ko) * | 2014-02-12 | 2015-09-08 | 주식회사 포티스 | 디지털 저장장치가 구비된 기기에 사용되는 컨텐츠 상황 알림 장치 |
| KR101483653B1 (ko) * | 2014-03-31 | 2015-01-16 | 주식회사 알엠 | 널 프레임을 이용한 영상 암호화 시스템 |
| MX372854B (es) * | 2014-11-25 | 2020-07-06 | Andrew Wireless Systems Uk Ltd | Detección de rellenador durante parada, pausa, retroceso y avance rápidos (trickplay). |
| US9756378B2 (en) | 2015-01-07 | 2017-09-05 | Echostar Technologies L.L.C. | Single file PVR per service ID |
| US10142707B2 (en) * | 2016-02-25 | 2018-11-27 | Cyberlink Corp. | Systems and methods for video streaming based on conversion of a target key frame |
| CN106874320A (zh) | 2016-06-20 | 2017-06-20 | 阿里巴巴集团控股有限公司 | 分布式流式数据处理的方法和装置 |
| CN106385633B (zh) * | 2016-09-27 | 2019-12-10 | 深圳市九洲电器有限公司 | 一种个人视频录像方法及系统 |
| US20200112710A1 (en) * | 2017-03-17 | 2020-04-09 | Lg Electronics Inc. | Method and device for transmitting and receiving 360-degree video on basis of quality |
| KR102484754B1 (ko) * | 2017-12-08 | 2023-01-06 | 삼성전자주식회사 | 영상처리장치 및 그 제어방법 |
| US11064153B2 (en) * | 2018-08-21 | 2021-07-13 | Gopro, Inc. | Methods and apparatus for encrypting camera media |
| CN118378759B (zh) * | 2024-06-21 | 2024-09-13 | 南昌工程学院 | 一种基于逆向云场景聚类的风电功率区间预测方法及系统 |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5717816A (en) * | 1993-01-13 | 1998-02-10 | Hitachi America Ltd. | Method and apparatus for the selection of data for use in VTR trick playback operation in a system using intra-coded video frames |
| US5377051A (en) * | 1993-01-13 | 1994-12-27 | Hitachi America, Ltd. | Digital video recorder compatible receiver with trick play image enhancement |
| US5477397A (en) * | 1993-02-23 | 1995-12-19 | Matsushita Electric Corporation Of America | Digital high definition television receiver with features that facilitate trick-play modes on a digital VCR |
| DE69525029T2 (de) * | 1994-09-13 | 2002-09-05 | Koninklijke Philips Electronics N.V., Eindhoven | Aufzeichnung und wiedergabe von datenreduzierten digitalen videosignalen auf einen longitudinalen aufzeichnungsträger |
| US5867625A (en) * | 1994-10-20 | 1999-02-02 | Thomson Consumer Electronics, Inc. | Digital VCR with trick play steam derivation |
| US6480664B1 (en) * | 1995-06-07 | 2002-11-12 | Hou-Chun Ting | Trick mode VTR which generates trick play data from a stream of images containing intra-pictures and predictive pictures and selects specific DCT coefficients for intra-pictures |
| US5793927A (en) * | 1995-06-07 | 1998-08-11 | Hitachi America, Ltd. | Methods for monitoring and modifying a trick play data stream to insure MPEG compliance |
| CN100518319C (zh) * | 1996-12-18 | 2009-07-22 | 汤姆森消费电子有限公司 | 将数据压缩成固定长度数据块及解压的方法 |
| CN1209018A (zh) * | 1997-08-19 | 1999-02-24 | 北海市自动化研究所 | 有线电视双向自动点播计费系统 |
| GB9721662D0 (en) * | 1997-10-14 | 1997-12-10 | Philips Electronics Nv | Encoded video signal formatting |
| EP1034656A2 (en) * | 1998-06-11 | 2000-09-13 | Koninklijke Philips Electronics N.V. | Trick play signal generation for a digital video recorder |
| US7046910B2 (en) * | 1998-11-20 | 2006-05-16 | General Instrument Corporation | Methods and apparatus for transcoding progressive I-slice refreshed MPEG data streams to enable trick play mode features on a television appliance |
| GB9930788D0 (en) * | 1999-12-30 | 2000-02-16 | Koninkl Philips Electronics Nv | Method and apparatus for converting data streams |
| JP2002016919A (ja) * | 2000-04-28 | 2002-01-18 | Sony Corp | 情報送信方法及び装置、情報受信方法及び装置、情報記録方法及び装置、並びに、情報記録再生方法及び装置 |
| KR20020091254A (ko) * | 2000-05-02 | 2002-12-05 | 제너럴 인스트루먼트 코포레이션 | 암호화된 비디오 스트림의 개별 화상에 대한 랜덤억세스를 가능하게 하기 위한 방법 및 장치 |
| US7054329B2 (en) * | 2000-07-07 | 2006-05-30 | Koninklijke Philips Electronics, N.V. | Collision avoidance in IEEE 802.11 contention free period (CFP) with overlapping basic service sets (BSSs) |
| US6453115B1 (en) * | 2000-08-31 | 2002-09-17 | Keen Personal Media, Inc. | Digital video recording system which generates an index data structure for displaying a video stream in trickplay mode |
| JP3778009B2 (ja) * | 2001-06-13 | 2006-05-24 | ソニー株式会社 | データ転送システム、データ転送装置、データ記録装置、データ管理方法 |
| US7463737B2 (en) * | 2001-08-15 | 2008-12-09 | Digeo, Inc. | System and method for conditional access key encryption |
| US7218635B2 (en) * | 2001-08-31 | 2007-05-15 | Stmicroelectronics, Inc. | Apparatus and method for indexing MPEG video data to perform special mode playback in a digital video recorder and indexed signal associated therewith |
| US7242773B2 (en) * | 2002-09-09 | 2007-07-10 | Sony Corporation | Multiple partial encryption using retuning |
| AU2003237462A1 (en) * | 2002-06-07 | 2003-12-22 | General Instrument Corporation | Seamless switching between multiple pre-encrypted video files |
| WO2003107664A1 (en) | 2002-06-12 | 2003-12-24 | Koninklijke Philips Electronics N.V. | Method and apparatus for processing a stream that contains encrypted information |
| 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 |
| CN1748423A (zh) * | 2003-02-10 | 2006-03-15 | 皇家飞利浦电子股份有限公司 | 加密视频信息的生成 |
| US20060277581A1 (en) * | 2003-03-10 | 2006-12-07 | Avraham Eliyahu | Local entity and a method for providing media streams |
-
2006
- 2006-04-25 CN CN2006800142862A patent/CN101167357B/zh not_active Expired - Fee Related
- 2006-04-25 BR BRPI0609561-5A patent/BRPI0609561A2/pt not_active IP Right Cessation
- 2006-04-25 JP JP2008508382A patent/JP2008539638A/ja active Pending
- 2006-04-25 MX MX2007013256A patent/MX2007013256A/es not_active Application Discontinuation
- 2006-04-25 RU RU2007143571/09A patent/RU2407214C2/ru not_active IP Right Cessation
- 2006-04-25 CN CN2010102983023A patent/CN101945250A/zh active Pending
- 2006-04-25 EP EP06728031A patent/EP1878232A2/en not_active Withdrawn
- 2006-04-25 KR KR1020077027542A patent/KR20070122577A/ko not_active Ceased
- 2006-04-25 WO PCT/IB2006/051277 patent/WO2006114759A2/en not_active Ceased
- 2006-04-25 US US11/912,316 patent/US20080273698A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006114759A2 (en) | 2006-11-02 |
| US20080273698A1 (en) | 2008-11-06 |
| CN101167357B (zh) | 2011-09-07 |
| MX2007013256A (es) | 2008-01-22 |
| JP2008539638A (ja) | 2008-11-13 |
| KR20070122577A (ko) | 2007-12-31 |
| EP1878232A2 (en) | 2008-01-16 |
| RU2407214C2 (ru) | 2010-12-20 |
| WO2006114759A3 (en) | 2007-01-18 |
| CN101945250A (zh) | 2011-01-12 |
| RU2007143571A (ru) | 2009-06-10 |
| CN101167357A (zh) | 2008-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0609561A2 (pt) | dispositivo e método para processar um fluxo de dados, meio legìvel por computador, e, elemento de programa para processar um fluxo de dados | |
| US8170210B2 (en) | Device for and a method of processing data stream | |
| KR100517463B1 (ko) | 데이터 스트림 프로세싱을 위한 시스템 | |
| BRPI0609564A2 (pt) | dispositivo e método para processar um fluxo de dados criptografados, meio legìvel por computador, e, elemento de programa para processar um fluxo de dados criptografados | |
| US8543724B2 (en) | Methods and apparatuses for a projected PVR experience | |
| WO2006114761A1 (en) | A device for and a method of detecting positions of intra-coded frames in a data stream | |
| JP2005531960A (ja) | 暗号化ｍｐｅｇトランスポートストリームからｍｐｅｇプログラムストリームを作成する方法 | |
| US20080212774A1 (en) | Device for and a Method of Processing an Encrypted Data Stream in a Cryptographic System | |
| US20110268427A1 (en) | Methods and apparatuses for a projected pvr experience | |
| US20080304810A1 (en) | Device for and a Method of Processing an Input Data Stream Comprising a Sequence of Input Frames | |
| WO2007072257A1 (en) | A device for and a method of processing an encrypted data stream | |
| US20110271001A1 (en) | Methods & apparatuses for a projected pvr experience | |
| WO2007072419A2 (en) | A device for and a method of processing a data stream | |
| WO2007072242A1 (en) | A device for and a method of processing an encrypted data stream |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 8A ANUIDADE. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2261 DE 06/05/2014. |
|
| B15K | Others concerning applications: alteration of classification |
Ipc: H04N 5/783 (2006.01), H04N 7/167 (2011.01) |