BRPI0614765A2 - protegendo conteúdo de fluxo elementar - Google Patents
protegendo conteúdo de fluxo elementar Download PDFInfo
- Publication number
- BRPI0614765A2 BRPI0614765A2 BRPI0614765-8A BRPI0614765A BRPI0614765A2 BR PI0614765 A2 BRPI0614765 A2 BR PI0614765A2 BR PI0614765 A BRPI0614765 A BR PI0614765A BR PI0614765 A2 BRPI0614765 A2 BR PI0614765A2
- Authority
- BR
- Brazil
- Prior art keywords
- mau
- field
- transport
- bit
- content
- Prior art date
Links
- 238000000034 method Methods 0.000 claims description 56
- 230000008569 process Effects 0.000 claims description 18
- 238000012545 processing Methods 0.000 claims description 5
- 238000005538 encapsulation Methods 0.000 claims description 4
- 238000013507 mapping Methods 0.000 description 33
- 239000012634 fragment Substances 0.000 description 23
- 230000005540 biological transmission Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 9
- 238000005070 sampling Methods 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 238000013467 fragmentation Methods 0.000 description 5
- 238000006062 fragmentation reaction Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000001824 photoionisation detection Methods 0.000 description 5
- 125000004122 cyclic group Chemical group 0.000 description 4
- 101100532690 Caenorhabditis elegans mau-2 gene Proteins 0.000 description 3
- 102100036309 MAU2 chromatid cohesion factor homolog Human genes 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000009877 rendering Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000013179 statistical model Methods 0.000 description 1
- 230000035900 sweating 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
- H04K—SECRET COMMUNICATION; JAMMING OF COMMUNICATION
- H04K1/00—Secret communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
-
- 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
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
-
- 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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
-
- 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/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
- H04N21/23476—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption by partially encrypting, e.g. encrypting the ending portion of a movie
-
- 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
- H04N21/44055—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 by partially decrypting, e.g. decrypting a video stream that has been partially encrypted
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/835—Generation of protective data, e.g. certificates
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
- H04L2209/603—Digital right managament [DRM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
PROTEGENDO CONTEúDO DE FLUXO ELEMENTAR Proteçào de conteúdo de mídia de fluxo elementar é descrita. Em um aspecto, segmentos de dados dentro de conteúdo de mídia de fluxo elementar são identificados. Cada segmento de dados inclui um único quadro de áudio e ou de video. Os limites de criptografia para proteger os pacotes de carga útil são selecionados para corresponderem aos limites de segmento de dados. O conteúdo de mídia de fluxo elementar é então protegido usando os limites de criptografia selecionados.
Description
"PROTEGENDO CONTEÚDO DE FLUXO ELEMENTAR"
Fundamentos da Invenção
Um centro de mídia tipicamente remove criptografiade um fluxo de transporte protegido carregando conteúdo demídia para desmultiplexar fluxo de transporte (TS) em fluxoselementares (ESs) para subseqüente re-criptografia, e entre-gar a um assinante de mídia (consumidores, clientes, etc.)por uma conexão de rede. Tais operações de descriptografia ere-criptografia pelo centro de mídia podem comprometer a se-gurança porque conteúdo descriptografado está vulnerável apirataria e outras brechas na segurança. "Conteúdo de mídia"é sinônimo de "conteúdo", e "sinais de mídia" que pode in-cluir um ou mais de vídeo, conteúdo de áudio, imagens, ani-mações, texto, etc.
Assinantes de mídia, tal como aparelhos de conexãoà TV via internet (STBs), receptores de mídia digital (D-MRs) , e computadores pessoais (PCs), tipicamente recebemconteúdo de mídia protegido de um centro de mídia, ou fontede conteúdo. Conteúdo de mídia protegido inclui dados de áu-dio/vídeo criptografados transmitidos por uma conexão de re-de, ou transferidos a partir de um meio de armazenamento.Para processar o conteúdo de mídia criptografado (por exem-plo, para indexação), um assinante de mídia tipicamente ne-cessita remover a proteção de conteúdo de mídia (isto é,descriptografar o conteúdo de mídia). Tais operações de des-criptografia tipicamente consomem recursos substanciais dedispositivo e reduzem o desempenho de dispositivo, e como umresultado, podem comprometer a resposta e funcionalidade dodispositivo.
Sumário da Invenção
Este sumário é fornecido para introduzir uma sele-ção de conceitos de uma forma simplificada que são adicio-nalmente descritos abaixo na Descrição Detalhada. Este sumá-rio não pretende identificar características chave ou carac-terísticas essenciais do assunto reivindicado, nem pretendeser usado como um auxílio na determinação do escopo do as-sunto reivindicado.
Em vista do acima, o conteúdo de mídia de fluxoelementar (ES) protegido é descrito. Em um aspecto, segmen-tos de dados no conteúdo de mídia ES são identificados. Cadasegmento de dados inclui um único quadro de vídeo ou áudio.Limites de criptografia para proteger pacotes de carga útilsão selecionados para corresponder a limites de segmento dedados. O conteúdo de mídia ES é então protegido usando oslimites de criptografia selecionados.
Breve Descrição dos Desenhos
A descrição detalhada é descrita com relação àsfiguras em anexo.
A FIG. 1 mostra um sistema de computação exempli-ficado para proteger conteúdo ES, de acordo com uma modali-dade.
A FIG. 2 mostra um ambiente de rede exemplificadono qual modalidades exemplificadas para proteger conteúdo EScarregado por um fluxo de transporte podem ser implementa-das, de acordo com uma modalidade.A FIG. 3 mostra aspectos exemplificados de opera-ções que utilizam Padrão de Criptografia Avançada no ModoContador para criptografar conteúdo de midia ES.
A FIG. 4 mostra um pacote de método de criptogra-fia exemplificado (TAG) para inserção junto com conteúdo ESprotegido no fluxo de transporte, de acordo com uma modali-dade.
A FIG. 5 mostra um procedimento exemplificado paraum transmissor proteger ESs em um fluxo de transporte, deacordo com uma modalidade.
A FIG. 6 mostra fluxo de transporte comumente co-dificado exemplificado, de acordo com uma modalidade.
A FIG. 7 ilustra uma estrutura de alto nivel exem-plificado de cabeçalho de Formato de Carga Útil (MPF) da U-nidade de Acesso à Midia (MAU), de acordo com uma modalidade.
A FIG. 8 mostra detalhes exemplificados do cabeça-lho MPF da FIG. 7, de acordo com uma modalidade.
A FIG. 9 ilustra uma seqüência exemplificada detrês pacotes de Pacote de Transporte em Tempo Real (RTP) queusa o MPF, de acordo com uma modalidade.
A FIG. 10 mostra um exemplo onde uma Unidade deAcesso à Midia (MAU) foi dividida em três fragmentos em ummesmo pacote RTP, de acordo com uma modalidade.
A FIG. 11 ilustra um cabeçalho RTP de 12 bytes padrão.
A FIG. 12 mostra um diagrama exemplificado de Cam-po de Bits 3 do MPF.A FIG. 13 mostra um diagrama exemplificado do cam-po de extensão de um cabeçalho MPF, de acordo com uma moda-lidade.
A FIG. 14 mostra um procedimento exemplificado pa-ra proteger conteúdo ES, de acordo com uma modalidade.
Descrição Detalhada da Invenção
Visão Geral
Sistemas e métodos para proteger conteúdo ES sele-cionando-se limites de criptografia baseado nas propriedadesespecificas de conteúdo de midia são descritos. Mais parti-cularmente, os sistemas e métodos criptografam (por exemplo,usando MPEG-2, etc.) partes de uma Unidade de Acesso à Midia(MAU) de um ES. Cada MAU é um único quadro de áudio ou vídeo(quadro de fluxo elementar) e cabeçalhos associados. Uma MAUinclui um ou mais segmentos de dados. Cada segmento de dadosé uma seção contígua de uma MAU a qual um mesmo conjunto deparâmetros de criptografia de conteúdo se aplica. Um segmen-to de dados é ou completamente criptografado ou completamen-te no claro (isto é, não criptografado) . Os ESs podem nãoter se originado de um TS. Entretanto, essas operações deproteção de ES são compatíveis com operações de cruzamentode sinais comuns aplicadas a um fluxo TS.
Se um TS contém conteúdo ES protegido, o TS é des-multiplexado em ESs enquanto preserva criptografia existente(isto é, o TS não é descriptografado) . Os ESs são mapeadosem um formato de carga útil de MAU (MPF) para encapsularMAUs de um ES em um protocolo de transporte (por exemplo,Protocolo de Transporte em Tempo Real (RTP)) para subseqüen-te comunicação com consumidores de mídia, tal como PCs e a-parelhos de conexão à TV via internet. 0 mapeamento de cadaMAU para o MPF fornece ao consumidor de mídia informação su-ficiente para processar (por exemplo, desmultiplexar, inde-xar, armazenar, etc.) cada ES independentemente de qualqueroutro ES, e processar cada MAU independentemente de qualqueroutra MAU. Essas técnicas estão em contraste co sistemasconvencionais, que não protegem conteúdo ES aplicando crip-tografia a partes da MAU compostas de um ou mais segmentosde dados.
Esses e outros aspectos dos sistemas e métodos pa-ra proteger conteúdo ES são agora descritos mais detalhada-mente com relação às FIGs. 1 até 14.
Aparelho Exemplificado
Para propósitos de discussão, e embora não exigi-do, a proteção de conteúdo ES é descrita no contexto geralde instruções executáveis por computador que são executadaspor um dispositivo de computação, tal como um computadorpessoal. Os módulos de programa geralmente incluem rotinas,programas, objetos, componentes, estruturas de dados, etc.,que executam tarefas particulares ou implementam tipos dedados abstratos particulares. Enquanto os sistemas e métodossão descritos no contexto anterior, ações e operações des-critas aqui podem também ser implementadas em hardware.
A FIG. 1 mostra um sistema exemplificado 100 paraproteger conteúdo ES. O sistema 100 inclui um dispositivo decomputação de propósito geral 102. O dispositivo de computa-ção 102 representa qualquer tipo de dispositivo de computa-ção, tal como um computador pessoal, um laptop, um servidor,dispositivo de computação portátil ou móvel, etc. 0 disposi-tivo de computação 102 inclui um processador 104 acoplado aomeio legível por computador 106. Os meios legíveis por com-putador 106 podem ser qualquer meio disponível acessível pe-lo dispositivo de computação 102, incluindo ambos meios vo-láteis e não voláteis (por exemplo, memória somente de lei-tura (ROM) e memória de acesso aleatório (RAM)), meios remo-víveis e não removíveis. Uma parte de RAM dos meios legíveispor computador 106 inclui módulos de programa e dados deprograma que são imediatamente acessíveis e/ou presentementesendo operados pelo processador 104.
A título de exemplo e não limitação, os meios le-gíveis por computador 106 incluem módulos de programa 108 edados de programa 110. Os módulos de programa 108 incluem,por exemplo, o módulo de proteção de ES 112, o módulo de ma-peamento de conteúdo ES protegido 114, e outros módulos deprograma 116 (por exemplo, um sistema operacional). O módulode proteção de ES 112 protege conteúdo de ES selecionandolimites de criptografia baseados em propriedades específicasde conteúdo de mídia. Mais particularmente, o módulo de pro-teção de ES 112 criptografa (por exemplo, usando MPEG-2,etc.) conteúdo de ES 118 para gerar conteúdo de ES protegido120. Para esse fim, o módulo de proteção de ES 112 aplicacriptografia a partes (isto é, segmentos de dados) de Unida-des de Acesso à Mídia (MAUs) que compreendem o ES. Em umaimplementação, as operações de criptografia são Padrão deCriptografia Avançada (AES) em Modo Contador. Cada MAU é umúnico quadro de áudio ou vídeo (quadro de fluxo elementar),que é subseqüentemente associado com cabeçalhos (por exem-plo, códigos de início e bits de enchimento). Cada MAU in-clui um ou mais segmentos de dados. Cada segmento de dados éuma seção contígua de uma MAU a qual o módulo de proteção deES 112 aplica um mesmo conjunto de parâmetros de criptogra-fia de conteúdo. 0 módulo de proteção de ES 112 ou completa-mente criptografa o segmento de dados, ou deixa o segmentode dados completamente não criptografado. Os ESs podem nãoter se originado de um TS. Entretanto, essas operações deproteção de Es são compatíveis com operações comuns de cru-zamento de sinais aplicadas a um fluxo TS (por exemplo, ver"outros dados" 122).
0 módulo de mapeamento de conteúdo de ES protegido114 ("módulo de mapeamento 114") mapeia conteúdo de ES pro-tegido 120 a um formato de carga útil de MAU (MPF) para en-capsulamento em pacotes de transporte 124. 0 MPF permite quepartes de uma MAU passem não criptografadas (deixadas noclaro). 0 MPF também fornece informação suficiente para per-mitir que um consumidor de mídia, tal como um computadorpessoal ou um aparelho de conexão à TV via internet (por e-xemplo, ver FIG. 2), processe cada ES protegido 120 indepen-dentemente de qualquer outro ES, e processe cada MAU no ESprotegido independentemente de qualquer outra MAU. O MPF édescrito mais detalhadamente abaixo com relação à seção in-titulada "Mapeamento de ES Protegido para Encapsulamento deProtocolo de Transporte". Em uma implementação, os pacotesde transporte correspondem a pacotes baseados no Protocolode Transferência em Tempo Real (RTP).
Em uma modalidade, o conteúdo de ES (por exemplo,conteúdo de ES 118) não se origina em um fluxo de transportede conteúdo de midia. Em uma outra modalidade, por exemplo,como descrito abaixo com relação à FIG. 2, o conteúdo de ESse origina em um fluxo de transporte. Adicionalmente, emborao sistema exemplificado 100 mostre o módulo de mapeamento deconteúdo de ES protegido 114 sendo implementado em um mesmodispositivo de computação como o módulo de proteção de ES112, o módulo de mapeamento 114 pode ser implementado em umdispositivo de computação diferente do dispositivo de compu-tação que implementa o módulo de proteção 112. Tal implemen-tação alternativa é descrita abaixo com relação à FIG. 2,onde operações do módulo de proteção 112 são implementadaspor uma fonte de conteúdo, e operações do módulo de mapea-mento 114 são implementadas por um centro de midia.
Sistema exemplificado
A FIG. 2 mostra um sistema exemplificado 200 paraproteger conteúdo de ES, onde o conteúdo de ES se origina emum fluxo de transporte, de acordo com uma modalidade. O flu-xo de transporte encapsula o conteúdo de midia. O sistema200 inclui, por exemplo, a fonte de conteúdo 202 e o centrode midia 204 acoplado pela rede 206 a um ou mais assinantes208. A fonte de conteúdo 100 pode estar associada com umservidor de videogame, um sitio da rede, um servidor de ví-deo, servidor de música, arquivo de software, base de dados,rede de televisão, etc. O módulo de cruzamento de sinais deTS 210 da fonte de conteúdo 202 criptografa o fluxo detransporte. Em uma implementação, a criptografia do fluxo detransporte 210 comum cruza sinais do fluxo de transporte. 0cruzamento de sinais comum permite que o fluxo de transportecriptografado seja processado (por exemplo, desmultiplexado,indexado, etc.) sem exigir que partes criptografadas do flu-xo sejam descriptografadas. O módulo de cruzamento de sinaisde TS 210 protege o conteúdo de ES que se origina no fluxode transporte como descrito acima com relação ao módulo deproteção de ES 112 da FIG. 1, à medida que as operações as-sociadas do módulo são compatíveis com operações comuns decruzamento de sinais aplicadas a um fluxo TS.
O centro de mídia 204 é um dispositivo de computa-ção centralmente localizado que pode ser acoplado à fonte deconteúdo 202 diretamente ou via a rede 206, por exemplo, u-sando o Protocolo de Controle de Transmissão/Protocolo deInternet (TCP/IP) ou outros protocolos de comunicação pa-drão. Exemplos de rede 206 incluem redes de IP, redes de te-levisão a cabo (CATV) e redes de satélite de transmissão di-reta (DBS). O centro de mídia 204 inclui o módulo de desmul-tiplexação e de mapeamento 212. Embora mostrado como um úni-co módulo de programa de computador, o módulo 212 pode serimplementado com um número arbitrário de módulos de programade computador. Operações de desmultiplexação de módulo deprograma 212 desmultiplexam o TS em respectivos Ess, semdescriptografar partes criptografadas do TS.
Operações de mapeamento do módulo de programa 212mapeiam conteúdo de ES protegido desmultiplexado para o MPF,como pelas operações descritas do módulo de mapeamento deconteúdo de ES protegido 114 da FIG. 1, para subseqüente en-capsulamento em pacotes de transporte para comunicação em umconsumidor de midia. Como descrito acima, o MPF permite queo segmento de dados de uma MAU seja deixado não criptografa-do quando encapsulado em um pacote(s) de transporte. O MPFtambém fornece suficiente informação para permitir que umassinante de midia 208 processe um ES recebido e protegidoindependentemente de qualquer outro ES, e processe cada MAUassociada em um ES protegido independentemente de qualqueroutra MAU. O MPF é descrito mais detalhadamente abaixo comrelação à seção intitulada "Mapeamento de ES Protegido paraEncapsulamento de Protocolo de Transporte". Em uma implemen-tação, os pacotes de transporte correspondem a pacotes base-ados no Protocolo de Transferência em Tempo Real (RTP).
O centro de midia 204 comunica o conteúdo de ESencapsulado por uma rede 206 a um ou mais assinantes 208,onde o PC 214 e/ou o STB 216 recebe o conteúdo de midia. Oconteúdo de midia processado e renderizado no PC 214 podeser exibido em um monitor associado com o PC 214; e os si-nais de midia processados e renderizados no STB 216 podemser exibidos na televisão (TV) 218 ou em dispositivo de exi-bição similar. Em uma implementação, a TV 218 tem as capaci-dades do STB 216 integradas nela.
Análise de Cruzamento de Sinais Comum de Fluxo deTransporte
Em uma implementação, o conteúdo de ES é carregadopor um fluxo de transporte. Nesse cenário, o módulo de cru-zamento de sinais de TS 210 da fonte de conteúdo 202, anali-sa o fluxo de transporte por cruzamento de sinais comum. Emparticular, o fluxo de transporte é analisado em vista deexigências de dados para pelo menos um processo ao qual ofluxo de transporte pode ser submetido depois de ser cripto-grafado. Se a determinação é feita baseada em um modelo es-tatístico correspondendo a um ou mais dos processos, as exi-gências de dados limite podem ser determinadas para o pro-cesso particular que tem as exigências de dados mais exten-sivas (isto é, limite). Essa análise é executada para deter-minar quais partes do fluxo de transporte são passadas nãocriptografadas.
A análise de cruzamento de sinais comum pode in-corporar conhecimentos que qualquer pacote no fluxo detransporte que contém qualquer informação de cabeçalho é pa-ra passar não criptografada. Uma descrição de tais pacotes einformação de cabeçalho é fornecida abaixo com relação àFIG. 6. Pacotes contendo qualquer parte de informação de ca-beçalho PES ou qualquer parte dos "dados de cabeçalho extra"são passados não criptografados. Adicionalmente, pacotescontendo uma Marcação de Fluxo parcial ou completa passamnão criptografados.
TABELA 1
MARCAÇÕES EXEMPLIFICADAS PARA INDICAR SE OS DADOS SÃODEIXADOS NÃO CRIPTOGRAFADOS
<table>table see original document page 12</column></row><table><table>table see original document page 13</column></row><table>
Com relação à TABELA 1, a quantidade de dados aserem deixados não criptografados nessa implementação cor-responde ao comprimento da Marcação de Fluxo mais o Compri-mento Máximo de Carga Útil de Dados. Nota-se que a seção nãocriptografada pode iniciar antes da Marcação de Fluxo e ter-minar depois do comprimento combinado da Marcação de Fluxo ede um comprimento Máximo de carga útil de dados, contantoque o comprimento combinado não exceda, por exemplo, o com-primento de duas cargas úteis de pacote de TS consecutivas.Por exemplo, um Transmissor (por exemplo, fonte de conteúdo202 da FIG. 2, etc.) pode deixar entre 16 e 368 bytes nãocriptografados para uma Marcação de Fluxo que denota um Ca-beçalho de Seqüência (4 bytes para a Marcação de Fluxo mais12 bytes para o Comprimento Máximo de Carga Útil de Dados) .
É também possível ter alguma quantidade de dados apartir de uma MAU anterior deixada não criptografada, no ca-so em que a Marcação de Fluxo aparece próxima ao início daMAU atual. Em uma implementação, isso é permitido quando ocomprimento da seção não criptografada não excede 368 bytes.
Como qualquer parte de um fluxo de transporte podepassar não criptografada, modalidades adicionais alternati-vas podem observar cabeçalhos de quadro e cabeçalhos PEStendo cruzamento de sinais comum aplicado a esses se os da-dos contidos nestes não são usados para processar o fluxo detransporte sem descruzar os sinais.
Criptografia
A FIG. 3 é um diagrama de bloco que mostra aspec-tos exemplificados de operações que utilizam Padrão de Crip-tografia Avançada (AES) em Modo Contador para criptografarconteúdo de midia de ES. Os vários dados e operações, des-critos abaixo com relação à FIG. 3, representam operaçõesexemplificadas do módulo de proteção de ES 112 da FIG. 1 eoperações exemplificadas do módulo de cruzamento de sinaisde TS 210 da FIG. 2. Embora um segmento de dados possa terdiferentes definições baseadas no tipo de conteúdo sendoprotegido, quando criptografando ESs, uma MAU incluindoqualquer número de segmentos de dados, representa um únicoquadro de áudio ou video.
Com relação à FIG. 3, AES em Modo Contador cria umfluxo de bytes baseado em respectivos segmentos de dados dofluxo de transporte. O fluxo de bytes é passado por uma ope-ração XOR com quaisquer bytes de texto não criptografados doconteúdo para criar o conteúdo criptografado. O Gerador deFluxo Chave utiliza um AES redondo para gerar blocos de 16bytes de fluxo chave em um tempo. As entradas para o AES re-dondo são a chave de criptografia de conteúdo (KC) e a con-catenação de 18 bits de um ID de segmento de dados e o ID debloco no novo segmento. A saida do gerador de fluxo chave épassada por uma operação XOR, byte a byte, com os dados dobloco correspondente (i) do segmento de dados. No caso dosegmento de dados não ser regularmente divisivel por 16 by-tes, somente os bytes restantes do segmento de dados do úl-timo bloco são passados por uma operação XOR com o fluxochave e retidos para os dados criptografados iniciarem. UmaMAU e os cabeçalhos associados representam mais segmentos dedados.
A FIG. 4 mostra um pacote de método de criptogra-fia exemplificado ("TAG") para inserção em um fluxo detransporte que carrega ESs protegidos. Com relação à FIG. 4:
- Os bits de adaptation_field_control são configu-rados para IOb (campo de adaptação somente, sem carga útil),então não há exigência em incrementar o contador de continu-idade.
- 0 Cabeçalho AF inclui quatro bytes para seremcompatíveis com a especificação MPEG:
-Io Byte = Comprimento de Campo de Adaptação
- 2o Byte = Sinalizador de presença de Campode Adaptação (Dados privados = 0x02)
- 3o Byte = Comprimento de dados privados(Comprimento DRM)
4o Byte = Número de Versão (atualmente 0x00)
DrmGuid inclui o GUID configurado para{B0AA4966-3B39-400A-AC35-4 4F41B46C96B}.
- 0 base_counter sincroniza o contador AES para opacote criptografado que segue.
- 0 byte SM (Marcação de Fluxo) indica que o se-guinte pacote inclui o início de uma Marcação de Fluxo, apartir da qual os primeiros poucos bytes podem estar faltan-do.
- SM = 0. O próximo pacote carrega o iniciode um cabeçalho PES ou um cabeçalho PES inteiro.
- SM = 1. O próximo pacote inclui o iniciode uma Marcação de Fluxo.
- SM = 2. O próximo pacote inclui o iniciode uma Marcação de Fluxo, a partir da qual o primeiro byte(00) está faltando.
- SM = 3. O próximo pacote inclui o iniciode uma Marcação de Fluxo, a partir da qual os primeiros doisbytes (00 00) estão faltando.
- SM = 4. O próximo pacote inclui o iniciode uma Marcação de Fluxo, a partir da qual os primeiros trêsbytes (00 00 01) estão faltando.
- SM = outro. Reservado.
- Os parâmetros Private_DRM contêm um Descritor deSegmento de Dados, que inclui um conjunto de extensão de IDchave com o valor de ID chave correspondente. A extensão deVetor de Inicialização AES128 não está presente, visto que oID de segmento de dados é indicado na seção base_counter dopacote TAG.
- O pacote é enchido com OxFF.
Conseqüentemente, um pacote TAG é um único pacotede TS com um Identificador Chave (KID) que é inserido emfrente a cada unidade PES protegida. Nessa implementação, opacote TAG é usado para restaurar uma licença de Gerencia-mento de Direitos Digitais (DRM) combinada quando o conteúdoé entregue a um consumidor de mídia. A camada de proteção deconteúdo inclui uma chave AES de 128 bits em Modo Contador,onde as seguintes exigências se aplicam: 0 contador de 128bits é dividido em dois campos de 64 bits: 0 base_counter(MSB) e o minor_counter (LSB) . 0 base_counter e o mi-nor_counter são equivalentes ao ID de segmento de dados e aoID de bloco descritos acima. Um pacote TAG pode fornecer i-dentificação para o algoritmo de criptografia utilizado naparte criptografada do fluxo de transporte, para fornecerdados necessários para um descriptografador autorizado dedu-zir uma chave de descriptografia, e identificar aquelas par-tes do fluxo de transporte que passam não criptografadas oucriptografadas. Um pacote TAG pode incluir dados adicionaisidentificando quais partes do fluxo criptografado são usadaspara respectivos processos (desmultiplexação ou indexaçãopara modos controle de leitura ou extração de imagem reduzi-da). Ademais ainda, um pacote TAG é inserido em compatibili-dade com o fluxo de transporte multiplexado.
Um pacote TAG pode ser gerado em correspondênciacom todas as partes criptografadas de um fluxo de transpor-te. Alternativamente, os pacotes de método de criptografiapodem ser gerados em correspondência com pacotes individuaisou bytes de dados de carga útil PES criptografados. Assim,um pacote TAG pode ser gerado em correspondência com cadacabeçalho PES em um fluxo de transporte, em correspondênciacom um número pré-determinado de cabeçalhos PES em um fluxode transporte, ou em correspondência com um padrão pré-determinado de pacotes que passam não criptografados por ou-tros processos.
A FIG. 5 mostra um fluxo exemplificado de opera-ções para um transmissor para proteger conteúdo de ES em umfluxo de transporte (com comparado a quando o conteúdo de ESnão é carregado pelo fluxo de transporte), de acordo com umamodalidade. A seguinte lista descreve aspectos da FIG. 5.
- ser - Essa variável é configurada para "sim" seo pacote TS atual é usualmente cruzado, ou para "não" de ou-tra forma.
key_sync - Essa variável é configurada para"sim" se o transmissor está renovando a chave AES, ou para"não" de outra forma.
- PID (13 bits) - O valor PID do fluxo elementarselecionado.
- base_counter - Esse campo de 64 bits é exclusi-vamente definido pelo transmissor por toda a vida útil dotransmissor. Em uma implementação, os bits zero até 50 re-presentam o section_counter, e os bits 51 até 63 são reser-vados para o PID.
- Section_counter (51 bits) - Um contador cíclicoque é incrementado para cada transição não para sim da vari-ável de estado ser.
- Minor_counter - Um contador de 64 bits que é in-crementado para cada bloco de 16 bytes cruzados.
- i - Um contador de 4 bits que é incrementado pa-ra cada byte cruzado.scramblel6 - AESKEY[base_counter|minor_counter}.
Depois do evento de Substituição de Chave AES o-correr, um transmissor imediatamente para de cruzar todos osPIDs até que ele re-sincronize com cada componente PES. Essatransição garante que todos os PIDs do mesmo programa sãocruzados com a mesma chave. Quando definindo o estado ser, otransmissor configura, para cada pacote de TS recebido, avariável de estado ser para "não" se qualquer uma das se-guintes condições se aplicam:
- key_sync = sim
- O pacote de TS inclui todo ou parte de um cabe-çalho PES.
- O pacote de TS inclui todo ou parte de um oumais das Marcações de Fluxo listadas na seguinte tabela. Uma
Marcação de Fluxo é composta de um código de Inicio MPEG esua carga útil de dados seguinte, como mostrado anteriormen-te na TABELA 1.
A FIG. 6 mostra um fluxo de transporte exemplifi-cado, de acordo com uma modalidade. Um transmissor insere umpacote TAG em frente a qualquer pacote de TS deixado nãocriptografado. Como mostrado na FIG. 6, os seguintes doiscenários podem ocorrer. Caso A: Um pacote TAG é inserido emfrente a um pacote contendo todo ou parte de um cabeçalhoPES. Caso B: Um pacote TAG é inserido em frente de um pacotecontendo toda ou parte de uma Marcação de Fluxo.
Ademais, as modalidades não exigem que um pacoteTAG seja inserido no fluxo de transporte. Como um pacote TAGnão é necessário até um ponto de descriptografia, um pacoteTAG pode ser transmitido a um processador em banda ou forade banda (por exemplo, por uma tabela privada), contanto queele seja recebido pelo processador pelo ponto de descripto-grafia. Em adição, um pacote TAG pode ser transmitido a umalicença de uso de conteúdo que é então transmitida em bandaou fora de banda a um processador.
Mapeamento de ES Protegido em um Formato de CargaÚtil de MAU
0 ES protegido é mapeado para o MPF tal que seçõesde uma MAU em um fluxo de transporte usualmente cruzado sãodeixadas não criptografadas. Esse mapeamento permite que umconsumidor de midia processe cada MAU independentemente. Emuma implementação, um transmissor, tal como a fonte de con-teúdo 202 implementa essas operações de mapeamento.
A sintaxe de um cabeçalho RTP convencional é defi-nida em RFC-3550 e mostrada na FIG. 11. Junto com o cabeça-lho RTP, os sistemas 100 da FIG. Ieo sistema 200 da FIG. 2mapeiam conteúdo de ES protegido (por exemplo, conteúdo deES protegido 120 da FIG. 1) para um formato de Carga Útil deMAU (MPF). Entretanto, todos os fluxos de midia em uma apre-sentação multimídia não necessitam usar o mesmo MPF, e dife-rentes formatos de carga útil podem ser usados. Descreve-seagora como as MAUs são encapsuladas em MPF.
A FIG. 7 ilustra a estrutura de alto nível exem-plificada do Cabeçalho MPF, de acordo com uma modalidade. 0cabeçalho é mostrado em relação a um cabeçalho RTP padrão. 0cabeçalho MPF é inserido por um transmissor (por exemplo, ocomputador 102 da FIG. 1 e/ou o centro de mídia 204 da FIG.2) em frente de cada MAU, ou fragmento dessa, no pacote detransporte. Como mostrado na FIG. 7, o cabeçalho MPF nessaimplementação exemplificada é dividido em três seções. Cadaseção começa com um campo de bits de um byte, e é seguidapor um ou mais campos opcionais. Em alguns casos, até duasseções inteiras podem ser omitidas do cabeçalho MPF. Assim,este pode ser tão pequeno quanto um byte.
0 cabeçalho MPF é seguido por uma "carga útil". Acarga útil inclui uma MAU completa, ou um fragmento dessa. Acarga útil pode conter uma MAU parcial, permitindo que gran-des MAUs sejam fragmentadas através de múltiplas cargas ú-teis em múltiplos pacotes de transporte. A primeira cargaútil pode ser seguida por pares adicionais de cabeçalhos MPFe cargas úteis, como permitido pelo tamanho do pacote detransporte.
A primeira seção do cabeçalho MPF, que é chamada"Info Específica de Pacote" na FIG. 7, contém informação queé específica a todas as cargas úteis no pacote de transpor-te. A seção "Info Específica de Pacote" é somente incluídauma vez em cada pacote de transporte, no primeiro cabeçalhoMPF, que aparece diretamente seguindo o fim do cabeçalhoRTP. A segunda seção, chamada "Propriedades da MAU", contéminformação que descreve a carga útil. Por exemplo, essa se-ção especifica se a carga útil contém uma MAU que é um pontode sincronismo, tal como um I-frame de vídeo, e também espe-cifica como o tamanho da carga útil é determinado. Adicio-nalmente, essa seção contém informação para permitir que umreceptor analise o pacote de transporte se o pacote anteriorfoi perdido. Isso é útil de uma MAU é fragmentada através demúltiplos pacotes de transporte.
A terceira seção, chamada "Sincronização da MAU",fornece informação sobre várias estampas de tempo associadascom a MAU na carga útil. Por exemplo, essa seção especificacomo o tempo de apresentação da MAU é determinado. Essa se-ção também inclui mecanismos de extensão permitindo que in-formação adicional seja incluída no cabeçalho MPF.
A FIG. 8 mostra um diagrama detalhado exemplifica-do de um cabeçalho MPF da FIG. 7, de acordo com uma modali-dade. Cada uma das três seções 802 até 806 da FIG. 8 incluivários campos de cabeçalho individuais. Esses campos sãomostrados como caixas na FIG. 8. As alturas das caixas dãouma indicação dos tamanhos relativos dos campos de cabeça-lho. Entretanto, a figura não está inteiramente desenhada emescala, e deveria ser notado que o campo "Extensão" tem umtamanho variável.
Com relação à FIG. 8, o primeiro campo de cabeça-lho em cada uma das três seções é um campo de bits. Os ou-tros campos de cabeçalho em uma seção estão somente presen-tes se indicado por esse campo de bits da seção. Em algunscasos, uma seção inteira, incluindo seu campo de bits, podeser omitida. A seção de Informação (Info) de Especificaçãode Pacote inclui "Campo de Bits 1", e pode também incluirqualquer dos outros campos mostrados na FIG. 8. CabeçalhosMPF adicionais no mesmo pacote de transporte começam com"Campo de Bits 2" e incluem os campos na seção "Propriedadesda MAU" e na seção "Sincronização da MAU".
No caso mais simples possível, um pacote de trans-porte contém uma única MAU completa. Nesse caso, é possívelincluir todos os campos de cabeçalho. Entretanto, campos quenão são necessários podem ser omitidos. Cada uma das trêsseções do cabeçalho MPF tem um campo de bits que indicaquais, se houver algum, dos campos na seção estão presentes.
Por exemplo, o campo "Deslocamento", que especifi-ca o deslocamento de bytes para o fim da carga útil atual,não é necessário quando o pacote contém uma única carga ú-til, porque o comprimento da carga útil pode ser deduzidopelo tamanho do pacote de transporte. 0 bit "OP" no "Campode Bits 2" indica se o campo "Deslocamento" está presente.Se todos os bits no "Campo de Bits 3" são zero, então o pró-prio "Campo de Bits 3" pode ser omitido, e isso é indicadoconfigurando-se o bit "B3P" no "Campo de Bits 2" para zero.
É possível combinar múltiplas cargas úteis em umúnico pacote de transporte, o que se refere como "agrupamen-to". 0 campo "Deslocamento" indica o uso de "agrupamento".Se o campo "Deslocamento" está presente, um outro cabeçalhoMPF e uma outra carga útil podem seguir depois do fim dacarga útil atual. 0 campo "Deslocamento" especifica o númerode bytes no fim da carga útil atual, contado a partir do fimdo próprio campo "Deslocamento". Para determinar se um outrocabeçalho MPF segue o fim da carga útil atual, implementa-ções necessitam considerar não somente o valor do campo"Deslocamento", mas também o tamanho do pacote de transpor-te, e o tamanho da área de enchimento RTP, se houver algumano caso de RTP ser usado como o protocolo de transporte.
Uma única MAU pode ser dividida em múltiplas car-gas úteis. Isso é referido como "fragmentação". O uso prin-cipal para a fragmentação é quando uma MAU é maior do que oque pode se ajustar em um único pacote de transporte. O cam-po "F" no "Campo de Bits 2" indica se uma carga útil contémuma MAU completa ou um fragmento dessa.
Os campos na seção "Sincronização da MAU" deveriamsomente ser especificados no cabeçalho MPF para a carga útilque contém o primeiro fragmento de uma MAU. A única exceçãoa isso é se o campo "Extensão" na seção "Sincronização daMAU" contém uma extensão que é diferente para diferentesfragmentos da mesma MAU. Quando uma MAU é fragmentada, osbits "S", "Dl" e "D2" no "Campo de Bits 2" são somente sig-nificativos no cabeçalho MPF para a carga útil que contém oprimeiro fragmento. Portanto, receptores (consumidores demidia) ignoram esses bits se o valor do campo "F" é 0 ou 2.
Nessa implementação, uma MAU não é fragmentada amenos que ela seja muito grande para se ajustar em um únicopacote de transporte. Nessa implementação, um fragmento deuma MAU não é combinado com uma outra MAU, ou com um frag-mento de uma outra MAU, em um único pacote de transporte.Entretanto, receptores podem ainda manipular esses casos. Umexemplo disso é mostrado na FIG. 9.
A FIG. 9 ilustra uma seqüência exemplificada detrês pacotes de Pacote de Transporte em Tempo Real que usamo MPF, de acordo com uma modalidade. Os três pacotes detransporte carregam os dados de 4 MAUs. A quarta MAU é con-tinuada em um quarto pacote de transporte (não mostrado) . Afigura mostra como a fragmentação das MAUs pode ser usadapara criar pacotes de transporte de tamanho fixo, se assimdesejado. Como pode ser visto na figura, a MAU 2 é fragmen-tada através de dois pacotes de transporte. No primeiro pa-cote de transporte, o cabeçalho MPF para a MAU 2 especificaque a MAU 2 é continuada no próximo pacote de transporte.(Isso é sinalizado usando o campo "F" no Campo de Bits 2) .
0 segundo pacote de transporte começa com um cabe-çalho MPF que omite o campo "Sincronização da MAU", porqueesse campo para a MAU 2 já foi especificado no primeiro pa-cote de transporte. 0 campo "deslocamento" na seção "Propri-edades da MAU" é usado para encontrar o inicio do Cabeçalhoem Formato de Carga Útil para a MAU 3. Isso permite que ocliente decodifique a MAU 3 mesmo se o pacote de transporteanterior foi perdido. Similarmente, a figura mostra como aMAU 4 é fragmentada através do segundo e do terceiro pacotede transporte. Entretanto, a MAU 4 é tão grande que nenhumaMAU adicional pode ser inserida no terceiro pacote de trans-porte. Nesse exemplo, a MAU 4 é continuada em um quarto pa-cote de transporte, que não é mostrado. Em situações comoessa, o cabeçalho de Formato de Carga Útil do terceiro paco-te de transporte não necessita incluir o campo "Deslocamen-to", e pode ser possível omitir a seção "Propriedades daMAU" inteira. A parte restante do cabeçalho MPF então somen-te inclui a seção "Info Específica de Pacote" e pode ser tãopequena quanto um único byte.Se uma MAU é fragmentada em múltiplas cargas ú-teis, estas são usualmente carregadas em pacotes de trans-porte separados. Entretanto, esse MPF também permite múlti-plas cargas úteis para alguma MAU a ser carregada em um úni-co pacote de transporte.
Se uma carga útil no pacote de transporte contémum fragmento de uma MAU, isso é indicado pelo campo "F" no"Campo de Bits 2".
A FIG. 10 mostra um exemplo onde uma única MAU foidividida em três fragmentos em um mesmo pacote RTP, de acor-do com uma modalidade. Nesse exemplo, o campo "F" no primei-ro cabeçalho MPF é configurado para 1, para indicar que aprimeira carga útil contém o primeiro fragmento da MAU. Aseção "Sincronização da MAU" está presente somente nessaprimeira carga útil. O campo "F" no segundo cabeçalho MPF éconfigurado para 0, para indicar que sua carga útil contémum fragmento, que não é nem o primeiro nem o segundo frag-mento da MAU. O campo "F" no terceiro cabeçalho MPF é confi-gurado para 2, para indicar que sua carga útil contém o ul-timo fragmento da MAU.
Em adição ao relógio de amostragem RTP usual e re-lógio de parede, o MPF fornece várias estampas de tempo adi-cionais e noções de tempo, que são agora descritas. O cabe-çalho RTP tem uma única estampa no tempo, que especifica otempo no qual os dados no pacote foram amostrados. Essa es-tampa no tempo é às vezes chamada de relógio de amostragem.É útil notar que as estampas de tempo RTP de pacotes perten-centes a diferentes fluxos de midia não podem ser compara-das. A razão é que o relógio de amostragem pode rodar em di-ferentes freqüências para diferentes fluxos de midia. Porexemplo, o relógio de amostragem de um fluxo de áudio poderodar em 44100 Hz, enquanto o relógio de amostragem de umfluxo de vídeo pode rodar em 90000 Hz. Além disso, RFC-3550especifica que o valor para a estampa de tempo RTP inicialdeveria ser escolhido de forma aleatória. De fato, cada flu-xo de mídia tem sua própria linha de tempo. Nesse documento,cada tal linha de tempo é referida como uma "linha de tempode mídia".
O RTP permite que as linhas de tempo para os dife-rentes fluxos de mídia sejam sincronizadas com a linha detempo de um relógio de referência, chamado "relógio de pare-de". Remetentes RTP permitem que o receptor execute essasincronização transmitindo um mapeamento entre o relógio deamostragem e o relógio de parede no pacote de Relatório deRemetente RTCP. Um Relatório de Remetente RTCP tem que serenviado para cada fluxo de mídia, porque os fluxos de mídiapodem usar diferentes relógios de amostragem.
Os mapeamentos são atualizados e transmitidos no-vamente em algum intervalo para permitir que o receptor cor-rija possível desvio entre o relógio de parede e os relógiosde amostragem. O desvio de relógio pode ainda ser um proble-ma se os desvios do relógio de parede do remetente em rela-ção ao relógio de parede do receptor. Os dois relógios pode-riam ser sincronizados usando o protocolo NTP, por exemplo,mas a especificação RTP não especifica um método de sincro-nização particular. Nota-se que o relógio de parede se ori-gina do codificador. Se o remetente RTP e o codificador sãoentidades separadas, o relógio de parede é tipicamente nãorelacionado a qualquer relógio físico no remetente.
Esse MPF usa uma terceira linha de tempo, chamadalinha de tempo de Tempo de Reprodução Normal (NTP). A linhade tempo NTP é útil principalmente quando RTP é usado paratransmitir uma "Apresentação" de mídia. Estampas de tempo apartir da linha de tempo NPT usualmente começam em 0 no iní-cio da apresentação. Estampas de tempo NPT são particular-mente úteis quando transmitindo uma apresentação pré-gravada, porque as estampas de tempo podem auxiliar o recep-tor em especificar uma posição para procurar na apresenta-ção. Isso assume a existência de algum mecanismo para o re-ceptor comunicar a nova posição ao remetente RTP.
Como o RTP foi projetado para aplicações de confe-rência multimídia, a especificação RTP não discute a linhade tempo NPT. Entretanto, outros protocolos que são constru-ídos no topo de RTP, tal como RTSP (um protocolo de controlepara aplicações de vídeo em demanda) incluem o conceito dalinha de tempo NPT. Em RTSP, o protocolo de transporte for-nece um mapeamento entre a linha de tempo NPT e a linha detempo de mídia para cada fluxo de mídia.
O MPF define um mecanismo para especificar a es-tampa de tempo da linha de tempo NPT associada com uma MAU.Entretanto, quando prático, um mapeamento fora de banda en-tre a linha de tempo de mídia e a linha de tempo NPT, talcomo uma definida por RTSP, pode ser preferencial, visto quereduz a sobrecarga do cabeçalho MPF.Todos os sistemas compatíveis com RTP manipulam oreinicio cíclico das estampas de tempo. Na freqüência de re-lógio típica de 90000 Hz, a estampa de tempo RTP reiniciaráde forma cíclica a cada 13 horas. Mas como a especificaçãoRTP diz que um deslocamento aleatório deveria ser adicionadoao relógio de amostragem, um receptor pode experimentar oprimeiro reinicio cíclico em substancialmente menos do que13 horas. 0 reinicio cíclico da estampa de tempo RTP é usu-almente manipulado usando aritmética modular. Quando esta éusada, as estampas de tempo são usualmente comparadas sub-traindo-se uma estampa de tempo de uma outra observando se oresultado é positivo ou negativo.
No MPF, cada MAU tem um "Tempo de Decodificação"e um "Tempo de Apresentação". 0 tempo de decodificação é otempo pelo qual a MAU deveria ser entregue ao decodificadordo receptor, e o tempo de apresentação é o tempo no qual aMAU deveria ser apresentada (exibida ou reproduzida) peloreceptor. Ambos os tempos pertencem à linha de tempo de mí-dia. Como os retardos na rede e no decodificador não são ti-picamente conhecidos ao remetente RTP, o receptor não usa osvalores absolutos de uma estampa de tempo de decodificaçãoou uma estampa de tempo de apresentação. 0 receptor conside-ra somente a diferença relativa entre um par de estampas detempo de decodificação ou um par de estampas de tempo de a-presentação.
Em alguns casos, tal como quando um codec de vídeoproduz quadros de vídeo bidirecionais, as MAUs podem ser de-codificadas em uma ordem diferente da que elas serão apre-sentadas. Nessa implementação, o remetente RTP transmite asMAUs na ordem que elas deveriam ser decodificadas.
O campo "Estampa de Tempo" no cabeçalho RTP mapeiao tempo de apresentação da primeira MAU no pacote de trans-porte. Como os pacotes de transporte são transmitidos na or-dem de decodificação, as estampas de tempo do tempo de apre-sentação de MAUs consecutivas podem não estar de forma monó-tona não decrescendo.
O cabeçalho MPF inclui um campo opcional "Tempo deDecodificação", que é usado para especificar o tempo de de-codif icação da MAU na carga útil. O cabeçalho MPF também in-clui um campo "Tempo de Apresentação" que é usado para espe-cificar o tempo de apresentação da MAU, quando o pacote detransporte contém mais do que uma MAU. Quando somente umaúnica MAU é incluída no pacote de transporte, o campo "Tempode Apresentação" porque o campo "Estampa de Tempo" serve co-mo substituição para esse campo na primeira MAU no pacote.Nessa implementação, ambos os campos "Tempo de Decodifica-ção" e "Tempo de Apresentação" são expressos usando a mesmaresolução de relógio como o campo "Estampa de tempo".
O termo "controle de leitura" refere-se ao recep-tor renderizando a apresentação de mídia em uma taxa de tem-po não real. Exemplos de controle de leitura incluem adian-tamento e retrocesso rápido da apresentação. Se o remetenteRTP está transmitindo no modo controle de leitura, a estampade tempo de decodificação e a estampa de tempo de apresenta-ção para cada MAU deveriam aumentar na taxa de tempo real.Isso permite que o decodificador decodifique as MAUs sem co-nhecer que o controle de leitura é usado. Os campos "Tempode Decodificação" e "Tempo de Apresentação" no cabeçalho MPFnão são afetados pelo controle de leitura, o campo "NPT", sepresente, não é. Por exemplo, se uma apresentação de mídiaestá sendo retrocedida, os campos de estampa de tempo "Tempode Apresentação" das MAUs estarão crescendo, enquanto o va-lor do campo "NTP" estará diminuindo.
0 campo "NPT" no cabeçalho MPF especifica a posi-ção na linha de tempo de Tempo de Reprodução Normal onde aMAU pertence. Se o campo "NPT" não está presente, um recep-tor pode calcular o tempo de reprodução normal da MAU a par-tir do tempo de apresentação, já que um mapeamento entre asduas linhas de tempo está disponível. Várias aproximaçõespara estabelecer esse mapeamento são discutidas abaixo. Comoo remetente RTP adiciona um deslocamento aleatório às estam-pas de tempo na linha do tempo de mídia, a estampa de tempode tempo de apresentação não é usada como uma substituiçãodireta para a estampa de tempo NPT. Mesmo se esse desloca-mento aleatório é conhecido ao receptor, o reinicio cíclicodas estampas de tempo da linha de tempo de mídia pode ser umproblema.
Uma solução possível para esses problemas é que oremetente use um mecanismo fora de banda para fornecer ummapeamento entre a linha de tempo de Tempo de ReproduçãoNormal e a linha de tempo de mídia. Esse mapeamento poderiaser fornecido somente uma vez no início da transmissão ourepetidamente se necessário. Adicionalmente, se a taxa decontrole de leitura para gerar estampas de tempo NPT que di-minuem à medida que o tempo de apresentação aumenta.
Se o mapeamento for fornecido somente uma vez noinicio da transmissão, o receptor estabelece um mapeamentoentre a linha de tempo de Tempo de Reprodução Normal e a li-nha de tempo de relógio de parede. Isso é usualmente possí-vel tão logo um pacote de Relatório de Remetente RTCP é re-cebido. É preferencial calcular a estampa de tempo NPT paracada MAU baseado no tempo de relógio de parede da MAU porqueas estampas de tempo da linha de tempo de mídia podem desvi-ar da linha de tempo do relógio de parede.
O protocolo RTSP é um exemplo de um protocolo decontrole que fornece um mapeamento entre a linha de tempo deTempo de Reprodução Normal e a linha de tempo de mídia noinício da transmissão. Uma outra solução, que pode forneceruma compensação entre complexidade e sobrecarga, é incluir ocampo "NPT" somente em MAUs de ponto de sincronização. Ocampo "NPT" é usado para estabelecer um mapeamento entre alinha de tempo de tempo de reprodução normal e as linhas detempo de apresentação e de relógio de parede. Para MAUs deponto de não sincronização, o receptor calcular a estampa detempo NPT usando o mapeamento anteriormente estabelecido.
Quando o controle de leitura é usado, o remetente incluiriao campo "NPT" para cada MAU.
O campo "Tempo de Transmissão" no cabeçalho MPFespecifica o tempo de transmissão do pacote de transporte.Isso pode ser útil quando uma seqüência de pacotes de trans-porte é transferida de um servidor para o segundo servidor.Somente o primeiro servidor necessita computar uma programa-ção de transmissão para os pacotes. 0 segundo servidor enca-minhará os pacotes de transporte a outros clientes baseadosno valor do campo "Tempo de Transmissão". Não é exigido in-cluir o campo "Tempo de Transmissão" quando encaminhando pa-cotes de transporte a um cliente. Entretanto, os clientespodem usar o campo "Tempo de Transmissão" para detectar con-gestionamento na rede comparando a diferença entre os valo-res dos campos "Tempo de Transmissão" em uma série de paco-tes com a diferença nos tempo de chegada de pacote. 0 campo"Tempo de Transmissão" usa as mesmas unidades como a linhade tempo de midia.
0 campo "Correspondência" fornece um mapeamentoentre a linha de tempo do relógio de parede e a linha detempo de midia atual. Quando RTP é o protocolo de transfe-rência, então esse é o mesmo mapeamento fornecido nos Rela-tórios de Remetente RTCP. Incluir o mapeamento no pacote detransporte é mais eficiente do que transmitir um pacote RTCPseparado. Isso permite que o remetente reduza a freqüênciados Relatórios de Remetente RTCP e ainda transmita o mapea-mento tão freqüentemente quanto desejado.
A FIG. 11 ilustra um cabeçalho RTP padrão de 12bytes para propósitos de referência. Com relação à FIG. 11:
- Campo "Versão" (V): 2 bits. Esse campo é confi-gurado para 2.
- Bit "Enchimento" (P): Esse bit é usado para adi-cionar enchimento ao fim do pacote RTP.- Bit "Extensão" (X) : Esse bit é configurado para1 se uma extensão de cabeçalho RTP está presente. 0 perfilRTP define como a extensão de cabeçalho é usada. Um receptoré capaz de analisar ou pular a extensão de cabeçalho que ocabeçalho RTP deveria ter um bit "Extensão" não zero.
- Campo "Fonte de Contribuição" (CC): 4 bits. Umreceptor é capaz de corretamente analisar, ou pular, a listade fontes de contribuição que o cabeçalho RTP deveria ter umcampo de fonte de contribuição não zero.
- Bit "Marcador" (M) : Esse bit é configurado para1 se quaisquer das cargas úteis no pacote de transporte con-têm uma MAU completa ou o último fragmento de uma MAU.
- Campo "Tipo de Carga Útil" (PT): 7 bits. A de-terminação de um tipo de carga útil RTP está fora do escopodeste documento. Ele é especificado pelo perfil RTP sob oqual esse Formato de Carga Útil é usado ou sinalizado dina-micamente fora de banda (por exemplo, usando SDP) .
- Campo "Número de Seqüência": 16 bits. Esse campocontém um número que aumenta em 1 para cada pacote de trans-porte enviado com o mesmo valor SSRC. O valor inicial do nú-mero de seqüência RTP pode ser comunicado ao cliente atravésde dispositivos não RTP.
- Campo "Estampa de Tempo": 32 bits. Esse campoespecifica a estampa de tempo que se aplica à primeira cargaútil que está incluída no pacote de transporte. Por padrão,o campo é interpretado como um tempo de apresentação. A fre-qüência de relógio do campo "Estampa de Tempo" é recomendadacomo sendo 90 kHZ, isto é, a resolução é 1/900000 segundos.O remetente e o receptor podem negociar uma freqüência derelógio diferente através de dispositivos não RTP.
- Campo "Fonte de Sincronização" (SSRC): 32 bits.Os pacotes de transporte com o mesmo valor para o campo SSRCcompartilham a mesma linha de tempo para o campo "Estampa deTempo" e o mesmo espaço de número para o campo "Número deSeqüência".
0 cabeçalho RTP é seguido por um cabeçalho MPF. Aúnica exceção é um pacote de transporte que somente incluienchimento. Nesse caso, o cabeçalho MPF não está presente.
Se um pacote de transporte contém dados para múltiplas MAUs,o cabeçalho MPF aparece em frente de cada MAU e em frente decada fragmento de MAU (parcial). Assim, os pacotes de trans-porte usando esse Formato de Carga Útil podem conter um oumais cabeçalhos MPF. 0 diagrama do cabeçalho MPF é mostradona FIG. 7. Quando o cabeçalho MPF diretamente segue o cabe-çalho RTP padrão de 12 bytes, ele começa com o campo de 1byte chamado "Campo de Bit 1", seguido por uma série de cam-pos opcionais. 0 cabeçalho é seguido por uma carga útil. Acarga útil inclui ou uma MAU completa ou um fragmento de MAU(parcial).
Depois da primeira carga útil de dados, um outrocabeçalho MPF pode aparecer, seguido por uma outra carga ú-til de dados. O processo de adicionar um outro cabeçalho MPFdepois de uma carga útil de dados pode ser repetido múlti-plas vezes. Cada cabeçalho MPF segue a primeira carga útilde dados com o campo "Campo de Bit 2".A seguir descreve-se o diagrama do campo "Campo deBit 1".
- Bit "Tempo de Transmissão Presente" (ST) : Se es-se bit é 1, um campo de 32 bits "Tempo de Transmissão" é in-serido diretamente seguindo o fim do campo "Campo de Bit 1".
- Bit "Correspondência Presente" (CP): Se esse bité 1, um campo de 96 bits "Correspondência" é inserido depoisdo campo "Tempo de Transmissão".
- R1, R2, R3 (1 bit cada) : Para cada um dessesbits que é configurado para 1, o receptor assume que um cam-po de 32 bits foi adicionado entre o campo "Correspondência"e o campo "Campo de Bit 2". O significado desses campos de32 bits não é definido nessa especificação. Um receptor quenão conhece o significado dos campos de 32 bits os ignora.
- R4, R5 (1 bit cada) : Reservado para uso futuro;atualmente configurado para 0.
- Bit "Campo de Bit 2 Presente" (B2P): Se esse bité 1, o campo de 1 byte "Campo de Bit 2" é inserido depois docampo "Correspondência".
- Campo "Tempo de Transmissão": 32 bits. Esse cam-po especifica o tempo de transmissão do pacote de transpor-te, usando as mesmas unidades de tempo que são usadas para ocampo "Estampa de Tempo" no cabeçalho RTP.
- Campo "Correspondência": 96 bits. O campo incluiduas estampas de tempo. Uma estampa de tempo de relógio deparede de 64 bits no formato NTP e uma estampa de tempo detempo de decodificação de 32 bits. Os dois campos são usadosda mesma forma como o campo "Estampa de tempo NTP" e o campo"Estampa de tempo RTP" no Relatório de Remetente RTCP", queé definido na seção 6.4.1 de RFC-3550.
Quando o "Campo de Bit 1" está presente, "Campo deBit 2" é opcional. 0 bit "B2P" no "Campo de Bit 1" determinase "Campo de Bit 2" está presente. 0 valor padrão para todosos bits no "Campo de Bit 2" é 0. 0 Campo "Fragmentação" (F)indica se a carga útil de dados inclui uma MAU parcial. Umaou mais tais cargas úteis são combinadas para reconstruiruma MAU completa. 0 campo "F" também indica se a carga útilcontém o primeiro ou último fragmento da MAU. Os bits "S","Dl" e "D2" (abaixo) são somente válidos quando o valor docampo "F" é 0 ou 3. A TABELA 2 mostra significados exempli-ficados do valor do campo F.
TABELA 2
<table>table see original document page 37</column></row><table>
- Bit "Deslocamento Presente" (OP): Se esse bit é1, o campo de 16 bits "Deslocamento" é inserido diretamentedepois do campo "Campo de Bit 2". 0 campo "Deslocamento" éusado para encontrar o fim da carga útil atual. Um outro ca-becalho MPF, comecando com "Campo de Bit 2" pode seguir ofim da carga útil atual. Se o bit "Deslocamento Presente" éΟ, ο campo "Deslocamento" está ausente; quando MPF é usadocom RTP, a carga útil atual se estende para o fim do pacotede transporte ou para o começo da área de enchimento RTP seo bit "Enchimento no cabecalho RTP é 1.
- Bit "Ponto de Sincronização" (S) : Esse bit éconfigurado para 1 quando a MAU é uma MAU de ponto de sin-cronização .
- Bit "Descontinuidade" (Dl) : Esse bit é configu-rado para 1 para indicar que uma ou mais MAUs estão faltan-do, mesmo que o número de seqüência dos pacotes de transpor-te (por exemplo, número de sequencia RTP, se RTP é usado)não indique uma "lacuna".
- Bit "Abandonável" (D2) : Se esse bit é 1, e é ne-cessário abandonar algumas MAUs, essas MAUs podem ser aban-donadas com menos impacto negativo do que as MAUs que têm obit D2 configurado para 0.
- Bit "Criptografia (E) : Esse bit é configuradopara 1 para indicar que a carga útil contém dados criptogra-fados. O bit deveria ser configurado para 0 se a carga útilnão contém dados criptografados.
- Bit "Campo de Bit 3 Presente" (B3P): Se esse bité 1, o campo de 1 byte "Campo de Bit 3" é inserido depois docampo "Comprimento".
- Bit "Deslocamento": Um campo de 16 bits que es-pecifica o deslocamento, em bytes, para o fim da carga útilatual, contado do primeiro byte seguindo o campo "Desloca-mento". Em outras palavras, o valor do campo "Deslocamento"é o tamanho da seção "Sincronização da MAU", se houver algu-mas, mais o tamanho da carga útil atual.
0 valor do bit "B3P" no "Campo de Bit 2" determinase o "Campo de Bit 3" está presente. 0 valor padrão para to-dos os bits no "Campo de Bit 3" é 0. A FIG. 12 mostra um di-agrama exemplificado do Campo de Bits 3 do MPF.
- Bit "Tempo de Decodificação Presente" (D3) : Seesse bit é 1, o campo de 32 bits "Tempo de Decodificação" éinserido depois do "Campo de Bit 3", mas antes do campo"Tempo de Apresentação".
- Bit "Tempo de Apresentação Presente" (P): Se es-se bit é 1, o campo de 32 bits "Tempo de Apresentação" é in-serido depois do campo "Tempo de Decodificação", mas antesdo campo "NPT".
- Bit "NPT Presente" (N): Se esse bit é 1, o campode 64 bits "NPT" é inserido imediatamente depois do campo"Tempo de Apresentação".
- R6, R7, R8, R9: Para cada um desses bit que éconfigurado para 1, o receptor assume que um campo de 32bits foi adicionado entre o campo "NPT" e o campo "Exten-são". 0 significado desses campos de 32 bits não é definidonesta especificação. Um receptor que não conhece o signifi-cado dos campos de 32 bits os ignora.
- Bit "Extensão Presente" (X): Se esse bit é 1, umcampo "Extensão" de tamanho variável é inserido depois docampo "NPT".
- "Tempo de Decodificação": Um campo de 32 bits.Esse campo especifica o tempo de decodificação da MAU. Quan-do RTP é usado, esse campo especifica o tempo de decodifica-ção da MAU usando as mesmas unidades de tempo que são usadaspara o campo "Estampa de Tempo" no cabeçalho RTP.
- "Tempo de Apresentação": Um campo de 32 bits.
Esse campo especifica o tempo de apresentação da MAU.
- Campo "NPT": Uma estampa de tempo de 64 bits. 0campo NPT especifica a posição da linha de tempo de Tempo deReprodução Normal à qual a MAU pertence.
A FIG. 13 mostra um diagrama exemplificado do cam-po extensão de um cabeçalho MPF, de acordo com uma modalida-de. O campo "Extensão" inclui uma ou mais coleções de cam-pos. A FIG. 13 ilustra o diagrama dos campos contidos em talcoleção.
- Bit "L": Se esse bit é 1, essa é a última cole-ção de campos "Extensão". Se o bit é 0, o fim do campo "Da-dos de Extensão" é seguido por pelo menos mais uma coleçãode campos "Extensão".
- "Tipo de Extensão": Um campo de 7 bits que é u-sado para identificar os conteúdos do campo "Dados de Exten-são". Em adição, os valores 0 e 127 são reservados para usofuturo.
- "Comprimento de Extensão": Um número de 8 bitsdando o tamanho, em bytes, do campo "Dados de Extensão" queaparece diretamente seguindo esse campo.
- "Dados de Extensão": Campo de comprimento variá-vel. O tamanho desse campo é dado pelo campo "Comprimenro deExtensão".Os campos no campo "Extensão" têm os seguintes va-lores quando a extensão Vetor de Inicialização é usada.
- "Tipo de Extensão": É 2.
- "Comprimento de Extensão": O tamanho do campo"Dados de Extensão", em bytes.
- "Dados de Extensão": Uma seqüência de um ou maisbytes, a ser usada como parte do vetor de inicialização daMAU atual. Quando essa extensão está presente, a unidade decriptografia é uma MAU completa. Se a MAU está fragmentadaem múltiplas cargas úteis, a extensão Vetor de inicializaçãoestá presente somente na primeira carga útil.
Os campos no campo "Extensão" têm os seguintes va-lores quando a extensão ID de Chave é usada.
- "Tipo de Extensão": É 3.
- "Comprimento de Extensão": 0 tamanho do campo"Dados de Extensão", em bytes.
- "Dados de Extensão": Uma seqüência de um ou maisbytes, que identificam a chave de descriptografia a ser usa-da para descriptografar a carga útil atual.
A extensão ID de Chave permanece eficaz até queseja substituída por uma extensão ID de Chave diferente.Portanto, a extensão é somente usada quando uma carga útilexige o uso de uma chave de descriptograf ia que é diferenteda chave de descriptografia da carga útil anterior. Entre-tanto, se a carga útil anterior estava contido em um pacotede transporte que foi perdido, o receptor pode não estar ci-ente de que uma mudança de chave de descriptografia é neces-sária. Se uma carga útil é descriptografada com a chave er-rada, e essa situacao não é detectada, pode levar a artefa-tos de renderização indesejados.
Uma aproximação para reduzir a severidade desseproblema é especificar a extensão ID de Chave para a primei-ra carga útil de cada MAU que é um ponto de sincronização.
Essa é uma boa solução se é conhecido que uma MAU perdidaforçará o receptor a descartar todas as MAUs até que ele re-ceba a próxima MAU de ponto de sincronização. Uma soluçãomais conservativa é especificar a extensão ID de Chave paraa primeira carga útil em cada pacote de transporte de múlti-plas cargas úteis. Essa solução é robusta contra perda depacote, visto que as cargas úteis interdependentes estão to-das contidas em um único pacote de transporte.
Quando cabeçalhos de video MPEG estão presentes,eles procedem para o quadro subsequente. Especificamente:
- Um Video_Sequence_Header MPEG, quando presente,está no inicio da MAU.
- Um GOP_header MPEG, quando presente, está no i-nicio da MAU, ou segue um Video_Sequence_Header.
- Um Picture_Header MPEG, quando presente, está noinicio de uma MAU, ou segue um GOP_header.
Diferente de RFC 2250, se uma MAU contendo video éfragmentada, não há exigência em executar fragmentação em umlimite de divisão.
As MAUs podem ser fragmentadas através de múlti-plos pacotes de transporte por diferentes razões. Por exem-plo, uma MAU pode ser fragmentada quando restrições de tama-nho de pacote de transporte existem e quando há diferençasem parâmetros de criptografia para partes especificas daMAU. Quando Campos de Cabeçalho RTP são interpretados, ocampo "Estampa de Tempo" no cabecalho RTP é configurado parao PTS da amostra com uma precisão de 90 kHz, e o campo "Tipode Carga Útil" (PT) é configurado de acordo com mecanismosde negociação fora de banda (por exemplo, usando SDP) . Comrelação ao MPF, a seção de informação de especificação depacote, a presença do campo "Tempo de Transmissão" é opcio-nal, a presença do campo "Correspondência" é opcional, e obit "Campo de Bit 2 Presente" (B2P) é configurado no caso dea carga útil conter uma parte de uma MAU que é criptografa-da, ou um fragmento de uma MAU que é criptografado.
Em vista do acima, o MPF permite que uma única MAUseja criptografada de acordo com diferentes parâmetros decriptografia. Isso inclui a capacidade de ter fragmentos deuma única MAU que são criptografados enquanto outros podemser deixados não criptografados. Em tais casos, uma MAU podeser fragmentada em múltiplas cargas úteis, cada uma com di-ferentes parâmetros de criptografia. Por exemplo, uma MAU ouum fragmento de uma MAU que é criptografada tem valores ecampos configurados de acordo com os seguintes critérios:
- O bit "Campo de Bit 2 Presente" (B2P) na seçãode Info de Pacote é configurado para 1, para indicar que um"Campo de Bit 2" está presente.
- O bit "Criptografia" (E) na seção Propriedadesda MAU é configurado para 1, para indicar que a carga útil écriptografada.- O bit "Extensão Presente" (X) na seção "Sincro-nização da MAU" é configurado para 1, para indicar a presen-ça de campos Extensão.
- Uma extensão "Vetor de Inicialização" é incluí-da. Os seguintes valores são configurados:
- 0 "Tipo de Extensão" é configurado para 2.
- 0 "Comprimento de Extensão" é configurado para 8(significando 64 bits) se o campo "Dados de Extensão" contémsomente um ID de segmento de dados, ou 16 (significando 128bits) se o campo "Dados de Extensão" contém ambos um ID desegmento de dados e um ID de bloco.
- 0 "Dados de Extensão" é configurado com o valorde ID de segmento de dados como descrito acima no caso do IDde bloco inicial ser zero. Se o ID de bloco inicial é dife-rente de zero, então o campo "Dados de Extensão" é configu-rado para o ID de segmento de dados seguido pelo ID de blocoinicial.
- Essa extensão é incluída para cada carga útilcriptografada de uma MAU.
- Uma extensão "ID de Chave" é incluída. Os se-guintes valores são configurados:
- 0 "Tipo de Extensão" é configurado para 3.
- 0 "Comprimento de Extensão" é configurado para16 (significando 128 bits).
- 0 "Dados de Extensão" é configurado com o valorde ID de Chave da licença que corresponde a essa MAU.
As extensões "Vetor de Inicialização" e "ID deChave" são incluídas para a primeira carga útil de uma novaMAU em cada pacote de transporte de múltiplas cargas úteisque contém múltiplas MAUs. Isso assegura que um receptor co-nheça o ID de Chave atual mesmo se alguns pacotes de trans-porte são perdidos.
A seção Propriedades da MAU é interpretada comosegue:
- 0 bit "Ponto de Sincronização" (S) é configuradoquando a MAU contém um I_Frame de Video ou um quadro de áudio.
- 0 bit "Descontinuidade" (Dl) é configurado quan-do uma ou mais MAUs estão faltando. Por exemplo, quando qua-dros de video foram abandonados por um tradutor de abandonode quadro-.
- A utilização do bit "Abandonável" (D2) é opcio-nal. Definir em quais casos ele deveria ser usado está forado escopo desta especificação.
- 0 bit "Criptografia" (E) é configurado no casoda carga útil conter uma parte de uma MAU que é criptografa-da, ou um fragmento de uma MAU que é criptografado.
A seção Sincronização da MAU é interpretada comosegue:
- 0 campo "Tempo de Decodificação" é opcional. Seusado, ele contém o DTS da MAU.
- 0 campo "Tempo de Apresentação" é opcional.
- 0 campo "NPT" é opcional.
0 bit "Extensão Presente" (X) é configuradoquando um ou mais cabeçalhos estão presentes.
Procedimento ExemplificadoA FIG. 14 mostra um procedimento exemplificado1400 para proteger conteúdo de ES, de acordo com uma modali-dade, Para propósitos de ilustração exemplificada, operaçõesdo procedimento 1400 são executadas por um ou mais do módulode proteção de ES 112 da FIG. 1, do módulo de mapeamento114, do módulo de cruzamento de fluxo de transporte 210 daFIG. 2, e/ou do módulo de desmultiplexação e empacotamento212. Várias mudanças e modificações estarão aparentes àque-les versados na técnica da presente descrição, incluindo mu-danças e modificações na ordem das ações.
Com relação à FIG. 14, no bloco 1405, fluxos ele-mentares (ESs) são recebidos ou de outra forma acessados pe-lo dispositivo de computação 102 ou fonte de conteúdo 2Ό2.Os ESs acessados podem ser independentes de um fluxo detransporte, ou carregados por um fluxo de transporte. Nobloco 1410, o procedimento 1400 protege partes da MAU dosESs. Em uma implementação, essas operações de proteção sãoexecutadas independente de cruzamento de sinais comum. Emuma outra implementação, essas operações de proteção são e-xecutadas usando cruzamento de sinais comum, por exemplo,quando cruzando um fluxo de transporte. No bloco 1415, se umfluxo de transporte foi acessado no bloco 1405, o fluxo detransporte é desmultiplexado em ESs tal que a criptografiaoriginal é mantida. Operações de desmultiplexação do módulo212 ilustram um componente exemplificado para executar ope-rações de desmultiplexação de fluxo de transporte.
No bloco 1420, o procedimento 1400 mapeia ESs pro-tegidos para o Formato de Carga Útil da MAU (MPF) . Mapeandocada MAU para o MPF fornece um consumidor de mídia que rece-be pacotes de transporte encapsulando os ESs mapeados comsuficiente informação para permitir que o consumidor de mí-dia processe cada ES independentemente de qualquer outro ES,e processe cada MAU independentemente de qualquer outra MAU.
No bloco 1430, o procedimento 1400 encapsula os ESs mapeadospara o MPF em um protocolo de transporte. Em uma implementa-ção, o protocolo de transporte é o Protocolo de Transporteem Tempo Real (RTP). No bloco 1440, o procedimento 1400 co-munica pacotes de transporte baseados no protocolo de trans-porte a um consumidor de mídia para processamento. Tal pro-cessamento, que inclui descriptografia, permite que o consu-midor de mídia experimente os dados de carga útil contidosnos pacotes de transporte.
Conclusão
Embora proteger conteúdo de ES tenha sido descritoem linguagem específica para características estruturaise/ou operações ou ações metodológicas, entende-se que as im-plementações definidas nas reivindicações em anexo não estãolimitadas às características específicas ou ações descritas.
De preferência, as características e operações específicassão descritas como formas exemplificadas de implementar oassunto reivindicado.
Claims (20)
1. Método implementado por computador,CARACTERIZADO pelo fato de que compreende:identificar os segmentos de dados de conteúdo defluxo elementar, cada segmento de dados compreende um únicoquadro de video ou de áudio;selecionar os limites de criptografia para prote-ção do conteúdo de fluxo elementar, os limites de criptogra-fia correspondentes aos segmentos de dados; eproteger o conteúdo de fluxo elementar usando oslimites de criptografia.
2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o conteúdo de fluxo elementaré carregado por um fluxo de transporte.
3. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que proteger adicionalmente com-preende criptografar os respectivos segmentos de dados comPadrão de Criptografia Avançada no Modo Contador.
4. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que proteger adicionalmente com-preende :analisar o fluxo de transporte para determinar aspartes do fluxo de transporte que estão para passar semcriptografia; eproteger adicionalmente compreende preparar o flu-xo de transporte para processamento que atravessa geralmentepartes cruzadas do fluxo de transporte.
5. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que um fluxo elementar do conteú-do de fluxo elementar compreende Unidades de Acesso à Mídia(MAUs), e proteger adicionalmente compreende:para cada MAU das MAUs, aplicar um conjunto res-pectivo de parâmetros de criptografia para cada segmento dedados de um ou mais segmentos de dados associados com a MAU,os respectivos parâmetros de criptografia ou criptografandoo segmento de dados ou deixando o segmento de dados nãocriptografado tal que os respectivos conjuntos de parâmetrosde criptografia se aplicam a cada segmento de dados separado.
6. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que cada segmento de dados é umaseção contígua da MAU.
7. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que uma parte da MAU é deixadanão criptografada.
8. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que o protocolo de transporte éum Protocolo de Transporte em Tempo Real (RTP).
9. Método, de acordo com a reivindicação 5,CARACTERIZADO adicionalmente pelo fato de que compreende ma-pear as MAUs para uma Formato de Carga Útil da MAU para oencapsulamento em um protocolo de transporte.
10. Método, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que o Formato de Carga Útil daMAU compreende informação específica de pacote associada comcada uma das MAU's.
11. Método, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que o Formato de Carga Útil daMAU compreende uma seção de propriedades da MAU para descre-ver uma MAU particular das MAUs; ese a MAU é fragmentada, a seção de propriedadesinclui informação para permitir que um receptor analise aMAU quando uma parte fragmentada da MAU é perdida.
12. Método, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que o Formato de Carga Útil daMAU compreende uma seção de sincronização da MAU para forne-cer informação sobre estampas de tempo associadas com umaMAU das MAUs.
13. Método, de acordo com a reivindicação 12,CARACTERIZADO pelo fato de que a informação compreende umcronograma de Tempo de Reprodução Normal (NPT) associado coma MAU, o NPT para auxiliar a especificação, por um receptor,uma posição para procurar em uma apresentação.
14. Método, de acordo com a reivindicação 12,CARACTERIZADO pelo fato de que a informação compreende umtempo de apresentação indicando quando o receptor está paraapresentar conteúdo da MAU.
15. Método implementado por computador,CARACTERIZADO pelo fato de que compreende:receber partes criptografadas de um fluxo elemen-tar (ES) , o ES é representado com múltiplas Unidades de A-cesso de Midia (MAUs), cada MAU corresponde a um único qua-dro de video ou áudio do ES, o ES é associado com informaçãoque permite que ele seja processado independente de qualqueroutro ES, e cada MAU é usada associada com informação permi-tindo que a MAU seja processada independente de qualquer ou-tra MAU; eprocessar o ES ou no mínimo uma MAU das MAUs.
16. Método, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que o fluxo elementar é carregadopor um fluxo de transporte geralmente cruzado.
17. Método, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que o ES é encapsulado por paco-tes de Protocolo de Transporte Em Tempo Real (RTP).
18. Método, de acordo com a reivindicação 15,CARACTERIZADO adicionalmente pelo fato de que o fluxo ele-mentar é carregado por um fluxo de transporte, e o processa-mento adicionalmente compreende demultiplexar o fluxo detransporte para derivar fluxos elementares.
19. Método implementado por computador,CARACTERIZADO pelo fato de que compreende:identificar Unidades de Acesso de Mídia (MAUs) doconteúdo de fluxo elementar;para cada MAU das MAUs, a MAU compreende um oumais segmentos de dados que representam um único quadro devídeo ou áudio, selecionando limites de criptografia basea-dos em um ou mais segmentos de dados para proteção do únicoquadro de vídeo ou áudio e cabeçalhos associados; eproteger o conteúdo de fluxo elementar baseado noslimites de criptografia tal que cada segmento de dados estáassociado com um conjunto respectivo de parâmetros de crip-tografia que é independente de outros parâmetros de cripto-grafia correspondentes do segmento de dados.
20. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que o conteúdo de fluxo elementaré carregado por um fluxo de transporte, proteger adicional-mente compreende geralmente cruzar o fluxo de transporte pa-ra prepará-lo para o processamento que atravessa o conteúdocriptografado.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/202.836 | 2005-08-12 | ||
| US11/202,836 US20060036551A1 (en) | 2004-03-26 | 2005-08-12 | Protecting elementary stream content |
| PCT/US2006/031546 WO2007022033A1 (en) | 2005-08-12 | 2006-08-10 | Protecting elementary stream content |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0614765A2 true BRPI0614765A2 (pt) | 2011-04-12 |
Family
ID=37757897
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0614765-8A BRPI0614765A2 (pt) | 2005-08-12 | 2006-08-10 | protegendo conteúdo de fluxo elementar |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US20060036551A1 (pt) |
| EP (1) | EP1913727A1 (pt) |
| JP (1) | JP2009505515A (pt) |
| KR (1) | KR20080033387A (pt) |
| CN (1) | CN101243640A (pt) |
| BR (1) | BRPI0614765A2 (pt) |
| MX (1) | MX2008001857A (pt) |
| RU (1) | RU2008105041A (pt) |
| WO (1) | WO2007022033A1 (pt) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8875199B2 (en) * | 2006-11-13 | 2014-10-28 | Cisco Technology, Inc. | Indicating picture usefulness for playback optimization |
| US8873932B2 (en) | 2007-12-11 | 2014-10-28 | Cisco Technology, Inc. | Inferential processing to ascertain plural levels of picture interdependencies |
| US8155207B2 (en) | 2008-01-09 | 2012-04-10 | Cisco Technology, Inc. | Processing and managing pictures at the concatenation of two video streams |
| US20080115175A1 (en) * | 2006-11-13 | 2008-05-15 | Rodriguez Arturo A | System and method for signaling characteristics of pictures' interdependencies |
| US8023973B2 (en) * | 2007-01-03 | 2011-09-20 | Motorola Solutions, Inc. | Expandable text messaging service protocol for use with a two-way radio transceiver |
| US7936873B2 (en) | 2007-05-07 | 2011-05-03 | Apple Inc. | Secure distribution of content using decryption keys |
| US8958486B2 (en) * | 2007-07-31 | 2015-02-17 | Cisco Technology, Inc. | Simultaneous processing of media and redundancy streams for mitigating impairments |
| US8804845B2 (en) * | 2007-07-31 | 2014-08-12 | Cisco Technology, Inc. | Non-enhancing media redundancy coding for mitigating transmission impairments |
| WO2009052262A2 (en) * | 2007-10-16 | 2009-04-23 | Cisco Technology, Inc. | Conveyance of concatenation properties and picture orderness in a video stream |
| US8155090B2 (en) * | 2007-11-01 | 2012-04-10 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for efficient multimedia delivery in a wireless packet network |
| US9892390B2 (en) * | 2007-12-12 | 2018-02-13 | Microsoft Technology Licensing, Llc | Digital content packaging, licensing and consumption |
| WO2009099366A1 (en) * | 2008-02-05 | 2009-08-13 | Telefonaktiebolaget L M Ericsson (Publ) | A method of transmitting sychnronized speech and video |
| US8886022B2 (en) | 2008-06-12 | 2014-11-11 | Cisco Technology, Inc. | Picture interdependencies signals in context of MMCO to assist stream manipulation |
| US8705631B2 (en) * | 2008-06-17 | 2014-04-22 | Cisco Technology, Inc. | Time-shifted transport of multi-latticed video for resiliency from burst-error effects |
| US8971402B2 (en) | 2008-06-17 | 2015-03-03 | Cisco Technology, Inc. | Processing of impaired and incomplete multi-latticed video streams |
| US8699578B2 (en) | 2008-06-17 | 2014-04-15 | Cisco Technology, Inc. | Methods and systems for processing multi-latticed video streams |
| EP2297964A4 (en) * | 2008-06-25 | 2017-01-18 | Cisco Technology, Inc. | Support for blocking trick mode operations |
| US8422679B2 (en) * | 2008-10-17 | 2013-04-16 | Motorola Solutions, Inc. | Method and device for sending encryption parameters |
| US20100218232A1 (en) * | 2009-02-25 | 2010-08-26 | Cisco Technology, Inc. | Signalling of auxiliary information that assists processing of video according to various formats |
| US8782261B1 (en) * | 2009-04-03 | 2014-07-15 | Cisco Technology, Inc. | System and method for authorization of segment boundary notifications |
| US8949883B2 (en) | 2009-05-12 | 2015-02-03 | Cisco Technology, Inc. | Signalling buffer characteristics for splicing operations of video streams |
| US8279926B2 (en) | 2009-06-18 | 2012-10-02 | Cisco Technology, Inc. | Dynamic streaming with latticed representations of video |
| US9185335B2 (en) | 2009-12-28 | 2015-11-10 | Thomson Licensing | Method and device for reception of video contents and services broadcast with prior transmission of data |
| EP2604031B1 (en) * | 2010-08-10 | 2017-03-08 | Google Technology Holdings LLC | Method and apparatus for streaming media content using variable duration media segments |
| CN102469344B (zh) * | 2010-11-16 | 2013-10-09 | 腾讯科技（深圳）有限公司 | 一种视频码流加、解密方法、装置及通信、存储终端 |
| KR20120084237A (ko) * | 2011-01-19 | 2012-07-27 | 삼성전자주식회사 | 엠엠티(ｍｍｔ)에서 엠엠티 인캡슐레이터를 전송하는 방법 |
| CN102737678B (zh) * | 2011-04-12 | 2016-12-07 | 上海广茂达光艺科技股份有限公司 | 一种灯光场景多媒体文件格式及其存储、同步播放方法 |
| JP5148765B1 (ja) * | 2011-09-06 | 2013-02-20 | 株式会社東芝 | 情報処理装置及び情報処理方法 |
| US9467424B2 (en) | 2011-10-07 | 2016-10-11 | Salesforce.Com, Inc. | Methods and systems for proxying data |
| US9008308B2 (en) * | 2012-02-08 | 2015-04-14 | Vixs Systems, Inc | Container agnostic decryption device and methods for use therewith |
| KR20140008237A (ko) * | 2012-07-10 | 2014-01-21 | 한국전자통신연구원 | 엠엠티의 하이브리드 전송 서비스에서 패킷 전송 및 수신 장치 및 방법 |
| US9197568B2 (en) * | 2012-10-22 | 2015-11-24 | Electronics And Telecommunications Research Institute | Method for providing quality of service in software-defined networking based network and apparatus using the same |
| US10237354B2 (en) * | 2014-09-25 | 2019-03-19 | Intel Corporation | Technologies for offloading a virtual service endpoint to a network interface card |
| CN108322778B (zh) * | 2018-02-09 | 2020-11-20 | 珠海迈科智能科技股份有限公司 | 一种提升dvb数据流加扰速度的方法及装置 |
| CN108322811A (zh) * | 2018-02-26 | 2018-07-24 | 宝鸡文理学院 | 一种钢琴视频教学中的同步方法及系统 |
| CN110213669B (zh) * | 2019-05-18 | 2021-03-23 | 杭州当虹科技股份有限公司 | 一种基于ts切片的视频内容防盗系统和方法 |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5420866A (en) * | 1994-03-29 | 1995-05-30 | Scientific-Atlanta, Inc. | Methods for providing conditional access information to decoders in a packet-based multiplexed communications system |
| US5684876A (en) * | 1995-11-15 | 1997-11-04 | Scientific-Atlanta, Inc. | Apparatus and method for cipher stealing when encrypting MPEG transport packets |
| US7809138B2 (en) * | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
| KR20010022752A (ko) * | 1998-06-11 | 2001-03-26 | 요트.게.아. 롤페즈 | 디지털 비디오 레코더용 트릭 플레이 신호 발생 |
| US6256071B1 (en) * | 1998-12-11 | 2001-07-03 | Hitachi America, Ltd. | Methods and apparatus for recording video files and for generating a table listing the recorded files and links to additional information |
| US7058803B2 (en) * | 2002-05-22 | 2006-06-06 | Broadcom Corporation | System and method for protecting transport stream content |
| US6931532B1 (en) * | 1999-10-21 | 2005-08-16 | International Business Machines Corporation | Selective data encryption using style sheet processing |
| US6941459B1 (en) * | 1999-10-21 | 2005-09-06 | International Business Machines Corporation | Selective data encryption using style sheet processing for decryption by a key recovery agent |
| US6961849B1 (en) * | 1999-10-21 | 2005-11-01 | International Business Machines Corporation | Selective data encryption using style sheet processing for decryption by a group clerk |
| US6654389B1 (en) * | 1999-11-23 | 2003-11-25 | International Business Machines Corporation | System and method for searching patterns in real-time over a shared media |
| KR100746821B1 (ko) * | 2000-04-21 | 2007-08-06 | 소니 가부시끼 가이샤 | 정보 처리 장치와 방법, 기록매체 |
| US7165175B1 (en) * | 2000-09-06 | 2007-01-16 | Widevine Technologies, Inc. | Apparatus, system and method for selectively encrypting different portions of data sent over a network |
| US6959090B1 (en) * | 2000-11-20 | 2005-10-25 | Nokia Corporation | Content Protection scheme for a digital recording device |
| JP2002197794A (ja) * | 2000-12-25 | 2002-07-12 | Toshiba Corp | 音声映像データ同期再生方法 |
| US7127619B2 (en) * | 2001-06-06 | 2006-10-24 | Sony Corporation | Decoding and decryption of partially encrypted information |
| JP4291525B2 (ja) * | 2001-07-31 | 2009-07-08 | 日本放送協会 | スクランブル方法、送信方法、送信装置、及び受信機 |
| US7242766B1 (en) * | 2001-11-21 | 2007-07-10 | Silicon Image, Inc. | Method and system for encrypting and decrypting data using an external agent |
| HUP0501109A2 (en) * | 2001-12-19 | 2006-03-28 | Irdeto Access Bv | Digital content distribution system |
| US7233669B2 (en) * | 2002-01-02 | 2007-06-19 | Sony Corporation | Selective encryption to enable multiple decryption keys |
| US7231516B1 (en) * | 2002-04-11 | 2007-06-12 | General Instrument Corporation | Networked digital video recording system with copy protection and random access playback |
| US7061942B2 (en) * | 2002-05-31 | 2006-06-13 | Skystream Networks Inc. | Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data |
| WO2004006579A1 (en) * | 2002-07-09 | 2004-01-15 | Kaleidescape, Inc. | Content and key distribution system for digital content representing media streams |
| US8015584B2 (en) * | 2002-10-18 | 2011-09-06 | Seachange International, Inc. | Delivering interactive content to a remote subscriber |
| WO2004045213A2 (en) * | 2002-11-13 | 2004-05-27 | General Instrument Corporation | Efficient distribution of encrypted content for multiple content access systems |
| US7298741B2 (en) * | 2003-02-27 | 2007-11-20 | Sharp Laboratories Of America, Inc. | Robust MPEG-2 multiplexing system and method using an adjustable time stamp |
| US7483532B2 (en) * | 2003-07-03 | 2009-01-27 | Microsoft Corporation | RTP payload format |
-
2005
- 2005-08-12 US US11/202,836 patent/US20060036551A1/en not_active Abandoned
-
2006
- 2006-08-10 KR KR1020087003328A patent/KR20080033387A/ko not_active Application Discontinuation
- 2006-08-10 WO PCT/US2006/031546 patent/WO2007022033A1/en active Application Filing
- 2006-08-10 JP JP2008526266A patent/JP2009505515A/ja active Pending
- 2006-08-10 RU RU2008105041/09A patent/RU2008105041A/ru not_active Application Discontinuation
- 2006-08-10 BR BRPI0614765-8A patent/BRPI0614765A2/pt not_active IP Right Cessation
- 2006-08-10 EP EP06801366A patent/EP1913727A1/en not_active Withdrawn
- 2006-08-10 CN CNA2006800293129A patent/CN101243640A/zh active Pending
- 2006-08-10 MX MX2008001857A patent/MX2008001857A/es not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| US20060036551A1 (en) | 2006-02-16 |
| EP1913727A1 (en) | 2008-04-23 |
| RU2008105041A (ru) | 2009-08-20 |
| JP2009505515A (ja) | 2009-02-05 |
| KR20080033387A (ko) | 2008-04-16 |
| WO2007022033A1 (en) | 2007-02-22 |
| MX2008001857A (es) | 2008-04-14 |
| CN101243640A (zh) | 2008-08-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0614765A2 (pt) | protegendo conteúdo de fluxo elementar | |
| BRPI0614675A2 (pt) | protegendo conteúdo de fluxo elementar | |
| JP4766473B2 (ja) | メディアデータコンテナとメタデータコンテナとを有するファイルを処理し読出すための装置および方法 | |
| US9641322B2 (en) | Container agnostic decryption device and methods for use therewith | |
| US8135949B2 (en) | Digital content distribution | |
| US7356147B2 (en) | Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient | |
| WO2005055075A1 (en) | Motion picture file encryption method and digital rights management method using the same | |
| NO339940B1 (no) | Nyttedata-format under RTP (Real-time Transport Protocol) | |
| US20080013726A1 (en) | Content transmission server and content transmission method | |
| EP2540054B1 (en) | Play-out control for a media data stream | |
| BR112012014465B1 (pt) | Dispositivo de recebimento de conteúdo, método de recebimento de conteúdo e meio legível por computador | |
| US9485533B2 (en) | Systems and methods for assembling and extracting command and control data | |
| WO2022127164A1 (zh) | 接口数据传输方法、装置、电子设备及存储介质 | |
| KR100840200B1 (ko) | Ｈ.２６４ 형식의 동영상 파일의 보호를 위한패키징/언패키징 장치 및 그 방법 | |
| US8897444B2 (en) | Information processing apparatus and information processing method | |
| US11445000B2 (en) | Multicast to unicast conversion | |
| BRPI0920333B1 (pt) | método e aparelho para distribuição segura de dados audiovisuais encapsulados de acordo com uma pluralidade de protocolos de transporte | |
| TWI450538B (zh) | 多媒體串流資料解密系統與方法 | |
| KR101215617B1 (ko) | 동영상 파일의 암호화 방법 및 그를 이용한 디지털 저작권 관리 방법 | |
| EP2665282A1 (en) | Data processing system and method | |
| AU2004224936A1 (en) | Encryption of MPEG Bitstreams |
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 6A 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: NAO APRESENTADA A GUIA DE CUMPRIMENTO DE EXIGENCIA. REFERENTE A 6A ANUIDADE. |