BRPI0614675A2 - protegendo conteúdo de fluxo elementar - Google Patents
protegendo conteúdo de fluxo elementar Download PDFInfo
- Publication number
- BRPI0614675A2 BRPI0614675A2 BRPI0614675-9A BRPI0614675A BRPI0614675A2 BR PI0614675 A2 BRPI0614675 A2 BR PI0614675A2 BR PI0614675 A BRPI0614675 A BR PI0614675A BR PI0614675 A2 BRPI0614675 A2 BR PI0614675A2
- Authority
- BR
- Brazil
- Prior art keywords
- mau
- field
- bad
- transport
- bit
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 57
- 230000008569 process Effects 0.000 claims abstract description 21
- 238000013507 mapping Methods 0.000 claims description 37
- 238000012545 processing Methods 0.000 claims description 7
- 238000005111 flow chemistry technique Methods 0.000 claims 1
- 230000001681 protective effect Effects 0.000 claims 1
- 239000012634 fragment Substances 0.000 description 22
- 230000005540 biological transmission Effects 0.000 description 8
- 238000005070 sampling Methods 0.000 description 6
- 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
- 101100532690 Caenorhabditis elegans mau-2 gene Proteins 0.000 description 3
- 102100036309 MAU2 chromatid cohesion factor homolog Human genes 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000005538 encapsulation Methods 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
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 241001440267 Cyclodes Species 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000013256 coordination polymer Substances 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000013179 statistical model Methods 0.000 description 1
- 230000035900 sweating Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
- H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
-
- 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
-
- 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
- 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/36—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols with means for detecting characters not meant for transmission
-
- 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
- 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/12—Details relating to cryptographic hardware or logic circuitry
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
PROTEGENDO CONTEúDO DE FLUXO ELEMENTAR. A presente invenção descreve proteger conteúdo de mídia de fluxo elementar. Em um aspecto, unidades de acesso de midia (MAU) de conteúdo de fluxo elementar são identificadas. Cada MAU inclui um ou mais segmentos de dados representando um único quadro de áudio ou vídeo. Limites de criptografia são selecionados para cada MAU. Os limites de criptografia são baseados em um ou mais segmentos de dados associados com a respectiva MAU. Partes de cada MAU são criptografadas com base em limites de criptografia correspondentes. Cada MAU é mapeada para um formato de carga útil de MAU. O formato de carga útil de MAU permite que um consumidor de mídia processe cada fluxo elementar associado com o conteúdo de fluxo elementar independente de qualquer fluxo elementar diferente. O formato de carga útil de MAU também permite que um consumidor de midia processe cada MAU em um fluxo elementar independente de qualquer outra MAU.
Description
"PROTEGENDO CONTEÚDO DE FLUXO ELEMENTAR"Fundamentos
Um centro de mídia tipicamente remove criptografiade um fluxo de transporte protegido transportando conteúdode mídia para demultiplexar o fluxo de transporte (TS) emfluxos elementares (ES) para subseqüente re-criptografia, eentrega para um assinante de mídia (clientes, consumidores,etc.) através de uma conexão de rede. Tais operações decriptografia e re-criptografia pelo centro de mídia podemcomprometer a segurança, pois o conteúdo decriptografado évulnerável à pirataria e outras brechas de segurança."Conteúdo de mídia" é sinônimo de "conteúdo" e "sinais demídia", que podem incluir um ou mais conteúdos de áudio,vídeo, imagens, animações, texto, etc. Assinantes de mídia, - tais como aparelhosdecodificadores (STB), receptores de mídia digital (DMR), ecomputadores pessoais (PC), tipicamente recebem conteúdo demídia protegido a partir de um centro de mídia, ou fonte deconteúdo. Conteúdo de mídia protegido inclui dados deáudio/vídeo criptografados transmitidos através de umaconexão de rede, ou transferidos a partir de um meio dearmazenamento. Para processar o conteúdo de mídiacriptografado (por exemplo, para indexação), um assinante demídia tipicamente necessita remover a proteção de conteúdode mídia (isto é, decriptografar o conteúdo de mídia). Taisoperações de decriptografia tipicamente consomem recursos dedispositivo substanciais e reduzem desempenho dodispositivo, e como resultado, podem comprometer afuncionalidade e sensibilidade do dispositivo.
Sumário
Este sumário é provido para introduzir uma seleçãode conceitos em uma forma simplificada que sãoadicionalmente descritos na descrição detalhada. Estesumário não é pretendido para identificar característicaschaves ou características essenciais da matériareivindicada, nem é pretendido para ser usado como umauxílio na determinação do escopo da matéria reivindicada.
Tendo em vista o exposto acima, conteúdo de mídiade fluxo elementar é descrito. Em um aspecto, unidades deacesso de mídia (MAU) de conteúdo ES são identificadas. CadaMAU inclui um ou mais segmentos de dados representando umúnico quadro de áudio ou vídeo. Limites de criptografia sãoselecionados para cada MAU. Os limites de criptografia sãobaseados em um ou mais segmentos de dados associados com orespectivo MAU. Partes de cada MAU são criptografadas combase em limites de criptografia correspondentes. Cada MAU émapeada para um formato de carga útil de MAU. 0 formato decarga útil de MAU permite que um consumidor de mídiaprocesse cada ES associado com o conteúdo de ES independentede qualquer ES diferente. 0 formato de carga útil de MAUtambém permite que um consumidor de mídia processe cada MAUem um ES independente de qualquer outra MAU.
Breve descrição dos desenhos
A descrição detalhada é descrita com referência àsfiguras que o acompanham.
A Figura 1 ilustra um sistema de computaçãoexemplar para proteger conteúdo de ES, de acordo com umamodalidade.
A Figura 2 ilustra um ambiente em rede exemplar noqual modalidades exemplares para proteger o conteúdo de EStransportado por um fluxo de transporte podem serimplementado, de acordo com uma modalidade.
A Figura 3 ilustra aspectos exemplares deoperações utilizando padrão de criptografia avançada em modode contador para criptografar o conteúdo de midia de ES.
A Figura 4 ilustra um pacote de método decriptografia exemplar (TAG) para inserção junto com conteúdode ES protegido no fluxo de transporte, de acordo com umamodalidade.
A Figura 5 ilustra um procedimento exemplar paraum transmissor para proteger os ES dentro de um fluxo detransporte, de acordo com uma modalidade.
A Figura 6 ilustra um fluxo de transporteembaralhado comumente exemplar, de acordo com umamodalidade.
A Figura 7 ilustra uma estrutura de alto nivelexemplar de cabeçalho de formato de carga útil (MPF) deunidade de acesso de midia (MAU), de acordo com umamodalidade.
A Figura 8 ilustra um detalhe exemplar docabeçalho de MPF da Figura 7, de acordo com uma modalidade.
A Figura 9 ilustra uma seqüência exemplar de trêspacotes de pacote de transporte em tempo real (RTP) que usamo MPF, de acordo com uma modalidade.A Figura 10 ilustra um exemplo onde uma únicaunidade de acesso de midia (MAU) foi dividida em trêsfragmentos em um mesmo pacote de RTP, de acordo com umamodalidade.
A Figura 11 ilustra um cabeçalho de RTP de 12bytes padrão.
A Figura 12 ilustra em esquema exemplar de campode bit 3 do MPF.
A Figura 13 ilustra um esquema exemplar do campode extensão de um cabeçalho . MPF, de acordo com umamodalidade.
A Figura 14 ilustra um procedimento exemplar paraproteger conteúdo de ES, de acordo com uma modalidade.
Descrição detalhada
Visão geral
Sistemas e métodos para proteger conteúdo de ESpela seleção de limites de criptografia com base empropriedades especificas de conteúdo de midia são descritos.Mais particularmente, os sistemas e métodos criptografam(por exemplo, utilizando MPEG-2, etc.) partes de uma unidadede acesso de midia (MAU) de um ES. Cada MAU é um únicoquadro de áudio ou video (quadro de fluxo elementar) ecabeçalhos associados. Uma MAU inclui um ou mais segmentosde dados. Cada segmento de dados é uma seção contígua de umaMAU à qual um mesmo conjunto de parâmetros de criptografiade conteúdo se aplicam. Um segmento de dados é oucompletamente criptografado ou completamente isento (isto é,não criptografado) . Os ES podem não ter se originado de umTS. No entanto, essas operações de proteção de ES sãocompatíveis com operações de embaralhamento comum aplicadasa um fluxo de TS.
Se um TS contém conteúdo de ES protegido, o TS édemultiplexado em ES enquanto preserva a criptografiaexistente (isto é, o TS não é decriptografado) . Os ES sãomapeados para um formato de carga útil de MAU (MPF) paraencapsular os MAU de um ES em um protocolo de transporte(por exemplo, protocolo de transporte em tempo real (RTP))para comunicação subseqüente para consumidores de mídia,tais como PC e aparelhos decodificadores. Mapear cada MAUpara o MPF prove um consumidor de mídia com informaçãosuficiente para processar (por exemplo, demultiplexar,indexar, armazenar, etc.) cada ES independentemente dequaisquer outros ES, e processar cada MAU independentementede quaisquer outras MAU. Essas técnicas contrastam comsistemas convencionais, os quais não protegem o conteúdo deES pela aplicação de criptografia às partes de MAU compostasde um ou mais segmentos de dados. Esses e outros aspectos dos sistemas e métodospara proteger conteúdo de ES são agora descritos em maioresdetalhes com referência às Figuras 1 a 14.
Aparelho exemplar
Para fins de discussão, e embora não exigido,proteger conteúdo de ES é descrito no contexto geral deinstruções executáveis por computador sendo executadas porum dispositivo de computação tal como um computador pessoal.Módulos de programa geralmente incluem rotinas, objetos,componentes, estruturas de dados, etc. que realizam tarefasparticulares ou implementam tipos de dados abstratosparticulares. Enquanto os sistemas e métodos são descritosno contexto antecedente, atos e operações descritas emseguida podem também ser implementadas em hardware.
A Figura 1 ilustra um sistema exemplar 100 paraproteger conteúdo de ES. O sistema 100 inclui um dispositivode computação de fim geral 102. O dispositivo de computação102 representa qualquer tipo de dispositivo de computaçãotal como um computador pessoal, um laptop, um servidor, umdispositivo de computação móvel ou portátil, etc. Odispositivo de computação 102 inclui um processador 104acoplado a uma midia legível por computador 106. A mídialegível por computador 106 pode ser qualquer mídiadisponível acessível por dispositivo de computação 102,incluindo ambas mídia volátil e não volátil (por exemplo,memória de somente leitura (ROM) e memória de acessoaleatório (RAM)), mídia removível e não removível. Uma parteda RAM da mídia legível por computador 106 inclui módulos deprograma e dados de programa que são imediatamenteacessíveis para e/ou presentemente sendo operados noprocessador 104.
Por meio de exemplo e não limitação, a mídialegível por computador 106 inclui módulos de programa 108 edados de programa 110. Os módulos de programa 108 incluem,por exemplo, módulo de proteção de ES 112, módulo demapeamento de conteúdo de ES 114, e outros módulos deprograma 116 (por exemplo, um sistema operacional). O módulode proteção de ES 112 protege o conteúdo de ES pela seleçãode limites de criptografia com base em propriedadesespecificas de conteúdo de midia. Mais particularmente, omódulo de proteção de ES 112 criptografa (por exemplo,usando MPEG-2, etc.) conteúdo de ES 118 para gerar conteúdode ES protegido 120. Para este fim, o módulo de proteção deES 112 aplica criptografia às partes (isto é, segmentos dedados) das unidades de acesso de midia (MAU) que compreendemo ES. Em uma implementação, as operações de criptografia sãopadrão de criptografia avançada (AES) em modo de contador.Cada MAU é um único quadro de video ou áudio (quadro defluxo elementar), que é subseqüentemente associado comcabeçalhos (por exemplo, códigos iniciais e bits depreenchimento) . Cada MAU inclui um ou mais segmentos dedados. Cada segmento de dados é uma seção contigua de umaMAU para a qual o módulo de proteção de ES 112 aplica ummesmo conjunto de parâmetros de criptografia de conteúdo. Omódulo de proteção de ES 112 ou criptografa completamente osegmento de dados, ou deixa o segmento de dadoscompletamente sem criptografia. Os ES podem não ter seoriginado de um TS. No entanto, as operações de proteção deES são compatíveis com operações de embaralhamento comunsaplicadas a um fluxo de TS (por exemplo, ver "outros dados"122) .
0 módulo de mapeamento de conteúdo de ES protegido114 ("módulo de mapeamento 114") mapeia o conteúdo de ESprotegido 120 para um formato de carga útil de MAU (MPF)para encapsulamento dentro de pacotes de transporte 124. 0MPF permite que partes de uma MAU passem não criptografadas(deixadas sem criptografia). 0 MPF também provê informaçãosuficiente para permitir que um consumidor de mídia, talcomo um computador pessoal ou um aparelho decodificador (porexemplo, ver Figura 2), processe cada ES protegido 120independentemente ou qualquer outro ES, e processe cada MAUno ES protegido independentemente de qualquer outra MAU. OMPF é descrito em maiores detalhes abaixo em referência àseção intitulada "Mapeando ES protegido para encapsulamentode protocolo de transporte". Em uma implementação, ospacotes de transporte correspondem a pacotes com base noprotocolo de 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 mídia. Em uma outra modalidade, por exemplo,como descrito abaixo em referência à Figura 2, o conteúdo deES não se origina em um fluxo de transporte. Adicionalmente,embora o sistema exemplar 100 ilustra um módulo demapeamento de conteúdo de ES protegido 114 sendoimplementado em um mesmo dispositivo de computação comomódulo de proteção de ES 112, módulo de mapeamento 114 podeser implementado em um dispositivo de computação diferentedo dispositivo de computação que implementa o módulo deproteção 112. Tal implementação alternativa é descritaabaixo em referência a Figura 2, onde operações do módulo deproteção 112 são implementadas por uma fonte de conteúdo, eoperações do módulo de mapeamento 114 são implementadas porum centro de mídia.Sistema exemplar
A Figura 2 ilustra um sistema exemplar 200 paraproteger conteúdo de ES, onde o conteúdo de ES se origina emum fluxo de transporte, de acordo com uma modalidade. 0fluxo de transporte encapsula conteúdo de mídia. 0 sistema200 inclui, por exemplo, fonte de conteúdo 202 e centro demídia 204 acoplado através da rede 206 a um ou maisassinantes de mídia 208. A fonte de conteúdo 100 pode estarassociada a um servidor de videojogo, um sítio da rede, umservidor de vídeo, um servidor de música, um arquivo desoftware, base de dados, rede de televisão, etc. Um módulode embaralhamento de TS 210 da fonte de conteúdo 202criptografa o fluxo de transporte. Em uma implementação, acriptografia de fluxo de transporte 210 comumente embaralhao fluxo de transporte. O embaralhamento comum permite que ofluxo de transporte criptografado seja processado (porexemplo, demultiplexado, indexado, etc.) sem exigir partescriptografadas do fluxo a ser decriptografado. O módulo deembaralhamento de TS 210 protege o conteúdo de ES que seorigina no fluxo de transporte como descrito acima comrelação ao módulo de proteção de ES 112 da Figura 1, àmedida que as operações associadas do módulo são compatíveiscom operações de embaralhamento comum aplicadas a um fluxode TS.
Um centro de mídia 204 é um dispositivo decomputação localizado centralmente que pode ser acoplado auma fonte de conteúdo 202 diretamente ou via rede 206, porexemplo, usando protocolo de controle detransmissão/protocolo de Internet (TCP/IP) ou outrosprotocolos de comunicação padrão. Exemplos de rede 206incluem redes IP, redes de televisão a cabo (CATV) e redesde satélite de transmissão direta (DBS). O centro de midia204 inclui módulo de mapeamento e demultiplexação 212.Embora ilustrado como um módulo de programa de computadorúnico, o módulo 212 pode ser implementado com um númeroarbitrário de módulos de programa de computador. Operaçõesde demultiplexação de módulo de programa 212 demultiplexam oTS em ES respectivos, sem partes criptografadas edecriptografadas do TS.
Operações de mapeamento de módulo de programa 212mapeiam o conteúdo de ES protegido demultiplexado para oMPF, conforme operações descritas de módulo de mapeamento deconteúdo de ES protegido 114 da Figura 1, para subseqüenteencapsulamento em pacotes de transporte para comunicação aum consumidor de midia. Como descrito acima, o MPF permiteque um segmento de dados de uma MAU seja deixado semcriptografia quando encapsulado em um pacote(s) detransporte. O MPF também provê suficiente informação parapermitir que um assinante de midia 208 processe um ESprotegido e recebido independentemente de qualquer outro ES,e processe cada MAU associada em um ES protegidoindependentemente de qualquer outra MAU. O MPF é descrito emmaiores detalhes em referência a seção intitulada "MapeandoES protegido para encapsulamento de protocolo detransporte". Em uma implementação, os pacotes de transportecorrespondem a pacotes com base em protocolo detransferência em tempo real (RTP).
O centro de mídia 204 comunica o conteúdo de ESprotegido encapsulado através de uma rede 206 para um oumais assinantes 208, onde PC 214 e/ou STB 216 recebe oconteúdo de mídia. O conteúdo de mídia processado erenderizado no PC 214 pode ser exibido em um monitorassociado com PC 214; e sinais de mídia processados erenderizados no STB 216 podem ser exibidos em uma televisão(TV) 218 ou dispositivo de exibição similar. Em umaimplementação, a TV 218 tem a capacidade de STB 216integrado na mesma.
Análise de embaralhamento comum de fluxo detransporte
Em uma implementação, o conteúdo de ES étransportado por um fluxo de transporte. Neste cenário, omódulo de embaralhamento de TS 210 da fonte de conteúdo 202,analisa o fluxo de transporte para embaralhamento comum. Emparticular, o fluxo de transporte é analisado em vista dassolicitações de dados para pelo menos um processo ao qual ofluxo de transporte pode ser sujeitado após sercriptografado. Se a determinação é feita com base em ummodelo estatístico correspondente a um ou mais processos,solicitações de dados limite podem ser determinadas para oprocesso em particular que tem as solicitações de dados maisextensivas (isto é, limite). Esta análise é realizada paradeterminar quais partes do fluxo de transporte devem passarnão criptografadas.
A análise de embaralhamento comum pode incorporarconhecimentos que qualquer pacote dentro do fluxo detransporte que contém qualquer informação de cabeçalho devepassar não criptografado. Uma descrição de tais pacotes einformações de cabeçalho é provida abaixo com referência àFigura 6. Pacotes contendo qualquer parte de informação decabeçalho de PES ou qualquer dos "dados de cabeçalho extra"devem passar não criptografados. Adicionalmente, pacotescontendo uma marcação de fluxo parcial ou completa devempassar não criptografados.
TABELA 1
MARCAÇÕES EXEMPLARES PARA INDICAR QUE DADOS SÃOPARA SEREM DEIXADOS NÃO CRIPTOGRAFADOS
<formula>formula see original document page 13</formula>
Com referência à TABELA 1, a quantidade de dados aser deixada sem criptografia nesta implementaçãocorresponde, ao comprimento da marcação de fluxo mais ocomprimento de carga útil de dados máximo. Note que a seçãosem criptografia pode iniciar antes da marcação de fluxo e ofim após o comprimento combinado da marcação de fluxo e umcomprimento de carga útil de dados máximo, contanto que ocomprimento combinado não exceda, por exemplo, o comprimentode duas cargas úteis de pacote de TS consecutivas. Porexemplo, um transmissor (por exemplo, a fonte de conteúdo202 da Figura 2, etc.) pode deixar entre 16 e 368 bytes semcriptografia por uma marcação de fluxo que denota umcabeçalho de seqüência (4 bytes para a marcação de fluxomais 12 bytes para o comprimento de carga útil de dadosmáximo).
Também é possível ter alguma quantidade de dados apartir de uma MAU anterior deixada sem criptografia, caso amarcação de fluxo apareça próxima ao início da MAU atual. Emuma implementação, isto é permitido quando o comprimento daseção sem criptografia não excede 368 bytes.
Desde que qualquer parte de um fluxo de transportepode passar não criptografada, modalidades alternativasadicionais podem contemplar cabeçalhos de quadro ecabeçalhos de PES possuindo embaralhamento comum aplicadoaos mesmos se os dados contidos nos mesmos não é usado paraprocessar o fluxo de transporte sem desembaralhamento.
Criptografia
A Figura 3 é um diagrama de bloco ilustrandoaspectos exemplares de operações utilizando padrão decriptografia avançada (AES) em modo de contador paracriptografar conteúdo de mídia de ES. Os vários dados eoperações descritas abaixo em referência à Figura 3,representam operações exemplares do módulo de proteção de ES112 da Figura 1 e operações exemplares do módulo deembaralhamento de TS 210 da Figura 2. Embora um segmento dedados pode ter diferentes definições com base no tipo deconteúdo sendo protegido, quando criptografando os ES, umaMAU incluindo qualquer número de segmentos de dados,representa um único quadro de video ou áudio.
Com referência à Figura 3, AES em modo de contadorcria um fluxo de bytes com base em segmentos de dadosrespectivos do fluxo de transporte. No fluxo de bytes érealizada uma operação XOR com quaisquer bytes de texto semcriptografia do conteúdo para criar o conteúdocriptografado. 0 gerador de fluxo de chave utiliza um ciclode AES para gerar blocos de 16 bytes de fluxo de chave em umperíodo. As entradas para o ciclo de AES são a chave decriptografia de conteúdo (KC) e a concatenação de 128 bitsde um ID de segmento de dados e do ID de bloco dentro donovo segmento. É realizada uma operação XOR da saída dogerador de fluxo de chave, byte a byte, com os dados dobloco correspondente (i) do segmento de dados. Caso osegmento de dados não for nem mesmo divisível por 16 bytes,será realizada a operação XOR somente nos bytes restantes dosegmento de dados do último bloco com o fluxo de chave eretido para os dados não criptografados definidos. Uma MAU,e cabeçalhos associados, representa mais segmentos de dados.
A Figura 4 ilustra um pacote de método decriptografia exemplar ("TAG") para inserção dentro de umfluxo de transporte que transporta os ES protegidos. Comreferência à Figura 4:
. Os bits adaptation_field_control são ajustadospara IOb (somente campo de adaptação, sem carga útil), entãonão existe solicitação para incrementar o contador decontinuidade.
. 0 cabeçalho de AF inclui quatro bytes para sercompatível com a especificação MPEG:
. Io byte = comprimento de campo de adaptação
2° byte = sinalizador de presença de campo deadaptação (dados privados = 0x02)
3o byte = comprimento de dados privados(comprimento de DRM)
. 4° byte = número de versão (atualmente 0x00). DrmGuid inclui o GUID ajustado para {B0AA4966-3B39-400A-AC35-44F41B46C96B}.
. O base_counter ressincroniza o contador de AESpara o pacote de dados que segue.
. Byte SM (marcação de fluxo) indica que o pacoteseguinte inclui o início de uma marcação de fluxo, a partirdo qual os primeiros poucos bytes podem estar faltando.
. SM = 0 - Próximo pacote transporta o início deum cabeçalho de PES ou um cabeçalho de PES total.
. SM = 1 - Próximo pacote inclui o início de umamarcação de fluxo. . SM = 2 - Próximo pacote inclui o início de uma
marcação de fluxo, a partir do qual o primeiro byte (00)está faltando.
. SM = 3 - Próximo pacote inclui o início de umamarcação de fluxo, a partir do qual os primeiros dois bytes(00 00) estão faltando.
. SM = 4 - Próximo pacote inclui o inicio de umamarcação de fluxo, a partir do qual os três primeiros bytes(00 00 01) estão faltando.
. SM = outro - Reservado.
. O Private_DRM_parameters contém um descritor desegmento de dados, o qual inclui uma extensão de ID de chaveajustada com o valor de ID de chave correspondente. Aextensão de vetor de inicialização de AES128 não estápresente, uma vez que o ID de segmento de dados é indicadona seção base_counter do pacote de TAG.
. O pacote é preenchido com OxFF.
Conseqüentemente, um pacote de TAG é um únicopacote de TAG com um identificador de chave (KID) que éinserido na frente de cada unidade de PES protegida. Nestaimplementação, o pacote de TAG é usado para recuperar umalicença de gerenciamento de direitos digitais correspondente(DRM) quando o conteúdo é entregue a um consumidor de midia.A camada de proteção de conteúdo inclui uma chave de 128bits de AES em modo de contador, onde as seguintesexigências se aplicam: o contador de 128 bits é dividido emdois campos de 64 bits: O base_counter (MSB) e ominor_counter (LSB). O base_counter e o minor_counter sãoequivalentes ao ID de segmento de dados e ao ID de blocodescritos acima. Um pacote de TAG pode prover identificaçãopara o algoritmo de criptografia utilizado na partecriptografada do fluxo de transporte, provê dadosnecessários para um descritor autorizado para deduzir umachave de decriptografia, e identifica aquelas partes dofluxo de transporte que passam não criptografadas oucriptografadas. Um pacote de TAG pode incluir adicionalmentedados identificando quais partes do fluxo criptografado sãousadas para respectivos processos (demultiplexar ou indexarpara modos de artificio ou extração de miniaturas) .Adicionalmente, um pacote de TAG é inserido em conformidadecom o fluxo de transporte multiplexado.
Um pacote de TAG pode ser gerado emcorrespondência com todas partes criptografadas de um fluxode transporte. Alternativamente, pacotes de método decriptografia podem ser gerados em correspondência com bytesou pacotes individuais de dados de carga útil de PES nãocriptografado. Assim, um pacote de TEAG pode ser gerado emcorrespondência com cada cabeçalho de PES em um fluxo detransporte, em correspondência com um número predeterminadode cabeçalhos de PES em um fluxo de transporte, ou emcorrespondência com um padrão predeterminado de pacotes quepassam não criptografados para outros processos.
A Figura 5 ilustra um fluxo exemplar de operaçõespara um transmissor para proteger conteúdo de ES dentro deum fluxo de transporte (comparado com quando o conteúdo deES não é transportado pelo fluxo de transporte) , de acordocom uma modalidade. A lista a seguir descreve aspectos daFigura 5.
scr - Esta variável é ajustada para "sim" se opacote de TS atual deva ser comumente embaralhado, ou para"não" caso contrário.
. key_sync - Esta variável é ajustada para "sim"se o transmissor estiver renovando a chave de AES, ou para"não" caso contrário.
PID (13 bits) - 0 valor de PID do fluxoelementar selecionado.
base_counter - Este campo de 64 bits éunicamente definido pelo transmissor durante o tempo de vidado transmissor. Em uma implementação, bits zero a 50representam o section_counter, e bits 51 a 63 são reservadospara o PID.
. section_counter (51 bits) - um contador cíclicoque é incrementado para cada transição de não para sim davariável de estado ser.
. minor_counter - um contador de 64 bits que éincrementado para cada bloco de 16 bytes embaralhados.
i - um contador de 4 bits que é incrementadopara cada byte embaralhado.
. scramblel6 - AESKEY [base_counter|minor_counter]
Após o evento substituir chave de AES ocorrer, umtransmissor imediatamente para de embaralhar todos os PIDaté que ele ressincronize com cada componente de PES. Estatransição garante que todos os PID do mesmo programa sejamembaralhados com a mesma chave. Quando definindo o estado deser, o transmissor ajusta, para cada pacote de TS recebido,a variável de estado de ser para "não" se qualquer dascondições seguintes se aplicar:
. key_sync = sim. O pacote de TS inclui todo ou parte de umcabeçalho de TS
. O pacote de TS inclui todo ou parte de uma oumais marcações de fluxo listadas na seguinte tabela. Umamarcação de fluxo é composta de um código de inicio MPEG-2 esua carga útil de dados seguinte, como ilustrado acima naTABELA 1.
A Figura 6 ilustra um fluxo de transporteexemplar, de acordo com uma modalidade. Um transmissorinsere um pacote de TAG na frente de qualquer pacote de TSdeixado sem criptografia. Como ilustrado na Figura 6, osdois cenários possíveis seguintes podem ocorrer. Caso A: Umpacote de TAG é inserido na frente de um pacote contendotodo ou parte de um cabeçalho de PES. Caso B: Um pacote deTAG é inserido na frente de um pacote contendo todo ou partede uma marcação de fluxo. Adicionalmente, modalidades nãorequerem que um pacote de TAG seja inserido dentro do fluxode transporte. Uma vez que um pacote de TAG não é necessárioaté um ponto de decriptografia, um pacote de TAG pode sertransmitido para um processador em banda ou fora de banda(por exemplo, por uma tabela privada), contanto que sejarecebido pelo processador pelo ponto de decriptografia. Alémdisso, um pacote de TAG pode ser transmitido para umalicença de uso de conteúdo que é então transmitida em bandaou fora de banda para um processador.
Mapeando ES protegido para um formato de cargaútil de MAU
ES protegido é mapeado para o MPF tal que seçõesde uma MAU em um fluxo de transporte comumente embaralhadosejam deixadas sem criptografia. Este mapeamento permite queum consumidor de mídia processe cada MAU independentemente.Em uma implementação, um transmissor tal como uma fonte deconteúdo 202 implementa essas operações de mapeamento.
A sintaxe de um cabeçalho de RTP convencional édefinida em RFC-3550 e ilustrada na Figura 11. Junto com ocabeçalho de RTP, sistemas 100 da Figura 1 e sistema 200 daFigura 2 mapeiam conteúdo de ES (por exemplo, conteúdo de ESprotegido 120 da Figura 1) para um formato de carga útil deMAU (MPF). No entanto, todos fluxos de mídia em umaapresentação multimídia não precisam usar um mesmo MPF, ediferentes formatos de carga útil podem ser usados.Descreve-se agora como as MAU são encapsuladas em MPF.
A Figura 7 ilustra uma estrutura alto-nívelexemplar do cabeçalho de MPF, de acordo com uma modalidade.O cabeçalho é ilustrado com relação a um cabeçalho de RTPpadrão. O cabeçalho de MPF é inserido por um transmissor(por exemplo, o computador 102 da Figura 1 e/ou o centro demídia 204 da Figura 2) na frente de cada MAU, ou fragmentodo mesmo, no pacote de transporte. Como ilustrado na Figura7, o cabeçalho de MPF nesta implementação exemplar édividido em três seções. Cada seção inicia com um campo debit de um byte, e é seguido por um ou mais campos opcionais.Em alguns casos, até duas seções inteiras podem ser omitidasdo cabeçalho de MPF. Assim, um cabeçalho de MPF pode ser tãopequeno quanto um byte.
O cabeçalho de MPF é seguido por uma "carga útil".A carga útil inclui uma MAU completa, ou um fragmento damesma. A carga útil pode conter uma MAU parcial, permitindograndes MAU serem fragmentadas em múltiplas cargas úteis emmúltiplos pacotes de transporte. A primeira carga útil podeser seguida por pares adicionais de cabeçalho de MPF ecargas úteis, como permitido pelo tamanho do pacote detransporte.
A primeira seção do cabeçalho de MPF, que échamada "Informação especifica de pacote" na Figura 7,contém informação que é especifica para todas cargas úteisno pacote de transporte. A seção "Informação especifica depacote" é somente incluída uma vez em cada pacote detransporte, no primeiro cabeçalho de MPF, que aparecediretamente seguindo o fim do cabeçalho de RTP. A segundaseção, chamada "Propriedades da MAU", contém informação quedescreve a carga útil. Por exemplo, esta seção especifica sea carga útil contém uma MAU que é um ponto de sincronização,tal como uma quadro I de vídeo, e também especifica como otamanho da carga útil é determinado. Adicionalmente, estaseção contém informação para permitir que um receptoranalise o pacote de transporte se o pacote de transporteanterior foi perdido. Isto é útil se uma MAU é fragmentadaem múltiplos pacotes de transporte.
A terceira seção, chamada "Temporização de MAU",provê informação sobre vários carimbos horários associadoscom a MAU na carga útil. Por exemplo, esta seção especificacomo o tempo de apresentação da MAU é determinada. Estaseção também inclui mecanismos de extensão permitindo queinformação adicional seja incluída no cabeçalho de MPF.
A Figura 8 ilustra um esquema detalhado exemplarde um cabeçalho de MPF da Figura 7, de acordo com umamodalidade. Cada das três seções 802 a 806 da Figura 8inclui diversos campos de cabeçalho individuais. Estescampos são ilustrados como caixas na figura 8. As alturasdas caixas dão uma indicação dos tamanhos relativos doscampos de cabeçalho. No entanto, a figura não estáinteiramente desenhada em escala, e deve ser notado que ocampo "extensão" possui um tamanho variável.
Com referência à Figura 8, o primeiro campo decabeçalho em cada das três seções é um campo de bit. Osoutros campos de cabeçalho em uma seção estão somentepresentes se indicados por aquele campo de bit da seção. Emalguns casos, uma seção inteira, incluindo seu campo de bit,pode ser omitida. A seção de informação de especificação depacote (Info) inclui "Campo de bit 1", e pode também incluirqualquer dos outros campos ilustrados na Figura 8.
Cabeçalhos de MPF adicionais no mesmo pacote de transporteiniciam com "Campo de bit 2" e incluem os campos na seção"Propriedades da MAU" e na seção "Temporização de MAU".
No caso mais simples possível, um pacote detransporte contém uma MAU única, completa. Neste caso, épossível incluir todos os campos de cabeçalho. No entanto,campos que não são necessários podem ser omitidos. Cada umadas três seções do cabeçalho de MPF possui um campo de bitque indica quais, se qualquer, dos campos na seção estãopresentes.Por exemplo, o campo "Deslocamento", queespecifica o deslocamento de byte para o fim da carga útilatual, não é necessário quando o pacote contém uma cargaútil única, pois o comprimento da carga útil pode serinferida pelo tamanho do pacote de transporte. O bit "OP" no"Campo de bit 2" indica se um campo "Deslocamento" estápresente. Se todos os bits no "Campo de bit 3" forem zero,então o próprio "Campo de bit 3" pode ser omitido, e isso éindicado pelo ajuste do bit "B3P" no "Campo de bit 2" parazero.
É possível combinar múltiplas cargas úteis em umúnico pacote de transporte. Isto é referido como"agrupamento". O campo "Deslocamento" indica o uso de"agrupamento". Se o campo "Deslocamento" estiver presente,outro cabeçalho de MPF e outra carga útil podem seguir apóso fim da carga útil atual. O campo "Deslocamento" especificao número de bytes até o fim da carga útil atual, contado dofim do próprio campo "Deslocamento". Para determinar seoutro cabeçalho de MPF segue o fim da carga útil atual,implementações precisam considerar não somente o valor docampo "Deslocamento" mas também o tamanho do pacote detransporte, e o tamanho da área de preenchimento de RTP, sequalquer no caso RTP é usado como o protocolo de transporte.
Uma única MAU pode ser dividida em múltiplascargas úteis. Isto é referido como "fragmentação". O usoprimário para fragmentação é quando uma MAU é maior que oque pode encaixar dentro de um único pacote de transporte. Ocampo "F" no "Campo de Bit 2" indica se uma carga útilcontém uma MAU completa ou um fragmento da mesma.
Os campos na seção "Temporização de MAU" deveriamsomente ser especificados no cabeçalho de MPF para a cargaútil que contém o primeiro fragmento de uma MAU. A únicaEXCEÇÃO A ISTO É SE 0 CAMPO "Extensão" na seção"Temporização de MAU" contém uma extensão que é diferentepara fragmentos diferentes da mesma MAU. Quando uma MAU éfragmentada, os bits "S", "Dl" e "D2" no "Campo de bit 2"são somente significantes no cabeçalho de MPF para a cargaútil que contém o primeiro fragmento. Portanto, receptores(consumidores de midia) ignoram esses bits se o valor docampo "F" for 0 ou 2.
Nesta implementação, uma MAU não é fragmentada anão ser que a MAU seja muito grande para se encaixar em umúnico pacote de transporte. Nesta implementação, umfragmento de uma MAU não é combinado com uma outra MAU, ouum fragmento de uma outra MAU, em um único pacote detransporte. No entanto, receptores podem ainda lidar comesses casos. Um exemplo disto é ilustrado na Figura 9.
A Figura 9 ilustra uma seqüência exemplar de trêspacotes de pacote de transporte em tempo real que usam oMPF, de acordo com uma modalidade. Os três pacotes detransporte transportam os dados de 4 MAU. A quarta MAU écontinuada em um quarto pacote de transporte (nãoilustrado). A figura ilustra como a fragmentação de MAU podeser usada para criar pacotes de transporte de tamanho fixo,se for desejado. Conforme pode ser visto na figura, a MAU 2é fragmentada em dois pacotes de transporte. No primeiropacote de transporte, o cabeçalho de MPF para a MAU 2especifica que a MAU 2 é continuada no próximo pacote detransporte. (Isto é sinalizado utilizando o campo "F" nocampo de bit 2).
0 segundo pacote de transporte inicia com umcabeçalho de MPF que omite o campo "Temporização de MAU",pois o campo "Temporização de MAU" para a MAU 2 já foiespecificado no primeiro pacote de transporte. 0 campo"Deslocamento" na seção "Propriedades da MAU" é usado paraencontrar o inicio do cabeçalho de formato de carga útilpara a MAU 3. Isto permite que o cliente decodifique a MAU 3até mesmo se o pacote de transporte anterior tiver sidoperdido. Similarmente, a figura ilustra como a MAU 4 éfragmentada nos segundo e terceiro pacotes de transporte. Noentanto, a MAU 4 é tão grande que nenhuma MAU adicional podeser inserida no terceiro pacote de transporte. Nesteexemplo, a MAU 4 é continuada em um quarto pacote detransporte, que não é ilustrado. Em tais situações, ocabeçalho de formato de carga útil do terceiro pacote detransporte não precisa incluir o campo "Deslocamento", e épossível omitir a seção "Propriedades da MAU" inteira. Aparte restante do cabeçalho de MPF então somente inclui aseção "Informação específica de pacote", e pode ser tãopequena quanto um único byte.
Se a MAU é fragmentada em múltiplas cargas úteis,as cargas úteis são usualmente transportadas em pacotes detransporte separados. No entanto, este MPF também permitemúltiplas cargas úteis para a mesma MAU a ser transportadadentro de um único pacote de transporte.
Se a carga útil no pacote de transporte contém umfragmento de uma MAU, isto é indicado pelo campo "F" no"Campo de bit 2".
A Figura 10 ilustra um exemplo onde uma única MAUfoi dividida em três fragmentos em um mesmo pacote de RTP,de acordo com uma modalidade. Neste exemplo, o campo xxF" noprimeiro cabeçalho de MPF é ajustado para 1, para indicarque a primeira carga útil contém o primeiro fragmento daMAU. A seção "Temporização da MAU" está presente somentenesta primeira carga útil. O campo "F" no segundo cabeçalhode MPF é ajustado para 0, para indicar que sua carga útilcontém um fragmento, que não é nem o primeiro nem o últimofragmento da MAU. O campo "F" no terceiro cabeçalho de MPF éajustado para 2, para indicar que sua carga útil contém oúltimo fragmento da MAU.
Em adição ao usual relógio de amostragem de RTP erelógio de parede, o MPF provê diversos carimbos horáriosadicionais e noções de tempo, que são agora descritas. Ocabeçalho de RTP possui um único carimbo horário, queespecifica o tempo no qual os dados no pacote sãoamostrados. Este carimbo horário é algumas vezes chamadocomo relógio de amostragem. É útil notar que os carimboshorários de RTP de pacotes pertencendo a diferentes fluxosde midia não podem ser comparados. A razão é que o relógiode amostragem pode rodar em diferentes freqüências paradiferentes fluxos de midia. Por exemplo, o relógio deamostragem de um fluxo de áudio pode rodar em 44100 Hz,enquanto o relógio de amostragem de um fluxo de vídeo poderodar a 90000 Hz. Além do mais, RFC-3550 especifica que ovalor para o carimbo horário de RTP inicial deve serescolhido aleatoriamente. Efetivamente, cada fluxo de mídiapossui sua própria linha do tempo. Neste documento, cada tallinha do tempo é referida como uma "linha do tempo demídia".
O RTP permite que as linhas do tempo para osdiferentes fluxos de mídia sejam sincronizadas com a linhado tempo de um relógio de referência, chamado de "relógio deparede". Os emissores de RTP permitem que o receptor executeessa sincronização pela transmissão de um mapeamento entre orelógio de amostragem e o relógio de parede no pacote derelatório de emissor de RTCP. Um relatório de emissor deRTCP diferente deve ser enviado para cada fluxo de mídia,pois os fluxos de mídia podem usar diferentes relógios deamostragem.
Os mapeamentos são atualizados e transmitidosnovamente em algum intervalo para permitir que o receptorcorrija um possível desvio entre o relógio de parede e osrelógios de amostragem. O desvio de relógio pode ainda serum problema se o relógio de parede do emissor desviar emrelação ao relógio de parede do receptor. Os dois relógiospoderiam ser sincronizados usando o protocolo de NTP, porexemplo, mas a especificação de RTP não especifica um métodode sincronização particular. Favor notar que o relógio deparede se origina do codificador. Se o emissor de RTP e ocodificador forem entidades separadas, o relógio de parede étipicamente não relacionado com qualquer relógio físico noemissor.
Este MPF usa uma terceira linha de tempo, chamadalinha de tempo de tempo de execução normal (NPT). A linha detempo de NPT é útil primariamente quando o RTP é usado paratransmitir uma "apresentação" de mídia. Carimbos horários dalinha de tempo de NPT comumente iniciam em 0 no início daapresentação. Os carimbos horários de NTP sãoparticularmente úteis quando transmitindo uma apresentaçãopré-gravada, pois os carimbos horários podem auxiliar oreceptor com a especificação de uma posição para buscardentro da apresentação. Isto assume a existência de algummecanismo para o receptor comunicar a nova posição para oemissor de RTP.
Tendo em vista que o RTP foi projetado paraaplicações de conferência multimídia, a especificação de RTPnão discute a linha de tempo de NPT. No entanto, outrosprotocolos que são construídos por cima do RTP, tal comoRTSP (um protocolo de controle para aplicações de vídeo sobdemanda) incluem o conceito da linha de tempo de NPT. EmRTSP, o protocolo de controle provê um mapeamento entre alinha de tempo de NPT e a linha de tempo de mídia para cadafluxo de mídia.
0 MPF define um mecanismo para especificar ocarimbo horário da linha do tempo de NPT associado "com umaMAU. No entanto, quando mapeamento fora de banda práticoentre a linha do tempo de mídia e a linha do tempo de NPT,tal como uma definida por RTSP, pode ser preferível, uma vezque reduz a sobrecarga do cabeçalho de MPF.
Todos sistemas complacentes com RTP manipulam ocircular de carimbos horários. Na freqüência de relógiotipica de 90000 Hzf o carimbo horário de RTP irá circularaproximadamente todas 13 horas. Mas uma vez que aespecificação de RTP diz que um deslocamento aleatóriodeveria ser adicionado ao relógio de amostragem, um receptorpode experimentar o primeiro circular em torno designificativamente menos de 13 horas. O circular do carimbohorário de RTP é usualmente manipulado pelo uso dearitmética modular. Quando a aritmética modular é usada,carimbos horários são usualmente comparados pela subtraçãode um carimbo horário de um outro e observando se oresultado é positivo ou negativo.
No MPF, cada MAU possui um "Tempo dedecodificação" e um "Tempo de apresentação". O tempo dedecodificação é o tempo pelo qual a MAU deveria ser entreguepara o decodificador do receptor, e o tempo de apresentaçãoé p tempo no qual a MAU deveria ser apresentada (exibida ouexecutada) pelo receptor. Ambos tempos pertencem à linha detempo de mídia. Tendo em vista que os retardos na rede e nodecodificador não são tipicamente conhecidos do emissor deRTP, o receptor não usa os valores absolutos de um carimbohorário de decodificação ou um carimbo horário deapresentação. O receptor considera somente a diferençarelativa entre um par de carimbos horários de decodificaçãoou um par de carimbos horários de apresentação.
Em alguns casos, tais como quando um codec devideo produz quadros de vídeo bidirecionais, as MAU podemser decodificadas em uma ordem diferente da qual elas serãoapresentadas. Nesta implementação, o emissor de RTPtransmite as MAU na ordem que elas deveriam serdecodificadas.
O campo "Carimbo horário" no cabeçalho de RTPmapeia o tempo de apresentação da primeira MAU no pacote detransporte. Tendo em vista que os pacotes de transporte sãotransmitidos em ordem de decodificação, os carimbos horáriosde tempo de apresentação das MAU consecutivas podem não sermonotonicamente não decrescente.
O cabeçalho de MPF inclui um campo "Tempo dedecodificação" opcional, que é usado para especificar otempo de decodificação da MAU na carga útil. O cabeçalho deMPF também inclui um campo "Tempo de apresentação" que éusado para especificar o tempo de apresentação da MAU,quando o pacote de transporte contém mais que uma MAU.Quando somente uma única MAU é incluída no pacote detransporte, o campo "Tempo de apresentação" devido ao campo"Carimbo horário" serve como uma substituição daquele campona primeira MAU no pacote. Nesta implementação, ambos oscampos "Tempo de decodificação" e "Tempo de apresentação"são expressos usando a mesma resolução de relógio que ocampo "Carimbo horário".
O termo "execução com artifício" se refere aoreceptor renderizando a apresentação de mídia em taxa detempo não real. Exemplos de execução com artifício incluemavanço rápido e retrocesso da apresentação. Se o emissor deRTP está transmitindo em modo de execução com artificio, ocarimbo horário de decodificação e o carimbo horário deapresentação para cada MAU deveriam incrementar em taxa detempo real. Isto permite que o decodificador decodifique asMAU sem saber que a execução com artificio é usada. Oscampos "Tempo de decodificação" e "Tempo de apresentação" nocabeçalho de MPF não são afetados pela execução comartificio, o campo "NPT", se presente, não é. Por exemplo,se uma apresentação de midia está sendo retrocedida, oscampos de carimbo horário "Tempo de apresentação" das MAUirão aumentar, enquanto o valor do campo "NPT" irádecrescer.
O campo "NPT" na cabeçalho de MPF especifica aposição na linha de tempo de tempo de execução normal onde aMAU pertence. Se o campo "NPT" não estiver presente, umreceptor pode calcular o tempo de execução normal da MAU apartir do tempo de apresentação, contanto que um mapeamentoentre as duas linhas de tempo esteja disponível. Váriasabordagens para estabelecer esse mapeamento são discutidasabaixo. Tendo em vista que o emissor de RTP adiciona umdeslocamento aleatório aos carimbos horários na linha detempo de mídia, o carimbo horário de tempo de apresentaçãonão é usado como uma substituição direta para o carimbohorário de NPT. Mesmo se esse deslocamento aleatório éconhecido do receptor, o circular dos carimbos horários dalinha de tempo de mídia pode ser um problema.
Uma solução possível para esses problemas é para oemissor usar um mecanismo fora de banda para prover ummapeamento entre a linha de tempo de tempo de execuçãonormal e a linha de tempo de mídia. Esse mapeamento poderiaser provido somente uma vez que no início da transmissão ourepetidamente como necessário. Adicionalmente, se a execuçãocom artifício é possível, o emissor comunica a taxa deexecução com artifício. Por exemplo, se a apresentação estásendo retrocedida, a taxa de execução com artifício énegativa. 0 receptor usa a taxa de execução com artifíciopara gerar os carimbos horários de NPT que decrescem àmedida que o tempo de apresentação aumenta.
Se o mapeamento é provido somente uma vez noinício da transmissão, o receptor estabelece um mapeamentoentre a linha de tempo de tempo de execução normal e a linhade tempo de relógio de parede. Isto é usualmente possíveltão logo que um pacote de relatório de emissor de RTCP érecebido. É preferível calcular o carimbo horário de NPTpara cada MAU com base no relógio de parede da MAU, pois oscarimbos horários da linha de tempo de mídia podem diferirda linha de tempo de relógio de parede.
O protocolo de RTSP é um exemplo de um protocolode controle que provê um mapeamento entre a linha de tempode tempo de execução normal e a linha de tempo de mídia noinício da transmissão. Outra solução, que pode prover umatroca adequada entre a complexidade e a sobrecarga, éincluir o campo "NPT" somente nas MAU de ponto desincronização. O campo "NPT" é usado para estabelecer ummapeamento entre a linha de tempo de tempo de execuçãonormal e as linhas de tempo de apresentação ou relógio deparede. Para as MAU de ponto de não sincronização, oreceptor calcula o carimbo horário de NPT usando omapeamento previamente estabelecido. Quando a execução comartificio é usada, o emissor incluiria o campo "NPT" paratoda MAU.
O campo "Tempo de envio" no cabeçalho de MPFespecifica o tempo de transmissão do pacote de transporte.Isto pode ser útil quando uma seqüência de pacotes detransporte é transferido de um servidor para um segundoservidor. Somente o primeiro servidor precisa computar umaprogramação de transmissão para os pacotes. O segundoservidor irá encaminhar os pacotes de transporte para outrosclientes com base no valor do campo "Tempo de envio". Não érequerido incluir o campo "Tempo de envio" quandoencaminhando pacotes de transporte para um cliente. Noentanto, clientes podem usar o campo "Tempo de envio" paradetectar congestionamento de rede para comparar a diferençaentre os valores dos campos "Tempo de envio" em uma série depacotes contra a diferença em tempos de chegada de pacote. Ocampo "Tempo de envio" usa as mesmas unidades que a linha detempo de mídia.
O campo "Correspondência" provê um mapeamentoentre a linha de tempo de relógio de parede e a linha detempo de mídia atual. Quando o RTP é o protocolo detransferência, então isto é o mesmo mapeamento provido nosrelatórios de emissor de RTCPP. Incluir o mapeamento nopacote de transporte é mais eficiente que transmitir umpacote de RTCP separado. Isto permite que o emissor reduza afreqüência dos relatórios de emissor de RTCP e aindatransmita o mapeamento tão freqüentemente quanto desejado.
A Figura 11 ilustra um cabeçalho de RTP de 12bytes padrão para fins de referência.
Com referência à Figura 11:campo "versão" (V) : 2 bits. Este campo éajustado para 2.
. bit de "Preenchimento" (P) : Este bit é usadopara adicionar preenchimento ao fim do pacote de RTP.
. bit de "Extensão" (X): Este bit é ajustado para1 se uma extensão de cabeçalho de RTP estiver presente. Operfil de RTP define como a extensão de cabeçalho é usada.
Um receptor é capaz de analisar ou pular a extensão decabeçalho se o cabeçalho de RTP tiver um bit de "Extensão"não zero.
. campo "Fonte de contribuição" (CC) : 4 bits. Umreceptor é capaz de analisar corretamente, ou pular, a listade fontes de contribuição se o cabeçalho de RTP tiver umcampo de fonte de contribuição não zero.
. bit de "Marcador" (M) : Este bit é ajustado para1 se qualquer das cargas úteis no pacote de transportecontém uma MAU completa ou o último fragmento de uma MAU.
campo "Tipo de carga útil" (PT): 7 bits. Aatribuição de um tipo de carga útil de RTP é fora do escopodeste documento. É especificada pelo perfil de RTP sob oqual este formato de carga útil é usado ou sinalizadodinamicamente fora de banda (por exemplo, usando SDP).
. campo "Número de seqüência": 16 bits. O campocontém um número que incrementa em 1 para cada pacote detransporte enviado com o mesmo valor de SSRC. 0 valorinicial do número de seqüência de RTP pode ser comunicadopara o cliente através de meios não RTP.
. campo "Carimbo horário": 32 bits. Este campoespecifica um carimbo horário que se aplica à primeira cargaútil que é incluída no pacote de transporte. Por padrão, ocampo é interpretado como um tempo de apresentação. Afreqüência do relógio do campo "Carimbo horário" érecomendada para ser 90 kHz, isto é, a resolução é 1/90000segundos. O emissor e receptor podem negociar uma freqüênciade relógio diferente através de meios não RTP.
. campo "Fonte de sincronização" (SSRC) : 32 bits.Pacotes de transporte com o mesmo valor para o campo SSRCcompartilham a mesma linha de tempo para o campo "Carimbohorário" e o mesmo espaço de número para o campo "Número deseqüência".
O cabeçalho de RTP é seguido por um cabeçalho deMPF. A única exceção é o pacote de transporte que somenteinclui preenchimento. Naquele caso, o cabeçalho de MPF nãoestá presente. Se um pacote de transporte contém dados demúltiplas MAU, o cabeçalho de MPF aparece na frente de cadaMAU e na frente de cada MAU fragmentada (parcial) . Dessaforma, pacotes de transporte usando esse formato de cargaútil podem conter um ou mais cabeçalhos de MPF. O esquema docabeçalho de MPF é ilustrado na Figura 7. Quando o cabeçalhode MPF segue diretamente o cabeçalho de RTP de 12 bytespadrão, ele começa com o campo de 1 byte chamado "Campo debit 1", seguido por uma série de campos opcionais. 0cabeçalho é seguido por uma carga útil. A carga útil incluiou uma MAU completa ou uma MAU fragmentada (parcial).
Após a primeira carga útil de dados, um outrocabeçalho de MPF pode aparecer, seguido por uma outra cargaútil de dados. O processo de adicionar um outro cabeçalho deMPF após uma carga útil de dados pode ser repetido múltiplasvezes. Cada cabeçalho de MPF que segue a primeira carga útilde dados com o campo "Campo de bit 2".
A seguir, é descrito o esquema do campo "Campo debit 1".
. bit "Tempo de envio presente" (ST) : Se este bitfor 1, um campo "Tempo de envio" é inserido diretamenteseguindo o fim do campo "Campo de bit 1".
. bit "Correspondência presente" (CP): Se este bitfor 1, um campo "Correspondência" é inserido após o campo"Tempo de envio".
RI, R2, R3 (1 bit cada) : Para cada um dessesbits que é ajustado para 1, o receptor assume que um campode 32 bits foi adicionado entre o campo "Correspondência" eo "Campo de bit 2". 0 significado desses campos de 32 bitsnão é definido neste relatório. Um receptor que não sabe osignificado dos campos de 32 bits, os ignora.
. R4, R5 (1 bit cada): Reservado para uso futuro;atualmente ajustado para 0.
. bit "Campo de bit 2 presente" (B2P): Se este bitfor 1, o campo "Campo de bit 2" de 1 byte é inserido após ocampo "Correspondência".campo "Tempo de envio": 32 bits. Este campoespecifica o tempo de transmissão do pacote de transporte,usando as mesmas unidades de tempo que são usadas para ocampo "Carimbo horário" no cabeçalho de RTP.
. campo "Correspondência": 96 bits. 0 campo incluidois carimbos horários. Um carimbo horário de relógio deparede de 64 bits em formato de NTP e um carimbo horário detempo de decodificação de 32 bits. Os dois campos são usadosda mesma forma que o campo "carimbo horário de NTP" e"carimbo horário de RTP" no relatório de emissor de RTCP,que é definido na seção 6.4.1 da RFC-3550.
Quando o "campo de bit 1" estiver presente, o"Campo de bit 2" é opcional. 0 bit "B2P" no "Campo de bit 1"determina se o "Campo de bit 2" está presente. 0 valorpadrão para todos bits no "Campo de bit 2" é 0. O campo"Fragmentação" (F) indica se a carga útil de dados incluiuma MAU parcial. Uma ou mais de tais cargas úteis écombinada para reconstruir uma MAU completa. O campo "F"também indica se a carga útil contém o primeiro ou últimofragmento da MAU. Os bits "S", "Dl", "D2" (abaixo) sãosomente válidos quando o valor do campo "F" for 0 ou 3. ATabela 2 ilustra significados exemplares do valor de campoF.
TABELA 2
<table>table see original document page 38</column></row><table><table>table see original document page 39</column></row><table>
Bit "Deslocamento presente" (OP): Se este bit for1, o campo "Deslocamento" de 16 bits é inserido diretamenteapós o "Campo de bit 2". 0 campo "Deslocamento" é usado paraencontrar o fim da carga útil atual. Um outro cabeçalho deMPF, iniciando com o "Campo de bit 2" pode seguir o fim dacarga útil atual. Se o bit "Deslocamento presente" for 0, ocampo "Deslocamento" está ausente; quando o MPF é usado comRTP, a carga útil atual se estende para o fim do pacote detransporte ou para o inicio da área de preenchimento de RTPse o bit "Preenchimento" no cabeçalho de RTP for 1.
Bit "Ponto de sincronização" (S): Este bit éajustado para 1 quando a MAU é uma MAU de ponto desincronização. Bit "Descontinuidade" (Dl) : Este bit éajustado para 1 para indicar que uma ou mais MAU estãofaltando, mesmo que o número de seqüência dos pacotes detransporte (por exemplo, o número de seqüência de RTP, se oRTP é usado) não indique um "espaço". Bit "Descontinuável"(D2) : Se este bit for 1, e é necessário descontinuar algumasMAU, essa MAU pode ser descontinuada com menos impactonegativo que as MAU que possuem o bit D2 ajustado para 0.Bit "Criptografia" (E) : Este bit é ajustado para 1 paraindicar que a carga útil contém dados criptografados. 0 bitdeveria ser ajustado para 0 se a carga útil não contém dadoscriptografados. Bit "Campo de bit 3 presente" (B3P): Se estebit for 1, o campo "Campo de bit 3" de 1 byte é inseridoapós o campo "Comprimento". "Deslocamento": um campo de 16bits que especifica o deslocamento, em bytes, para o fim dacarga útil atual, contado do primeiro byte seguindo o campo"Deslocamento". Em outras palavras, o valor do campo"Deslocamento" é o tamanho da seção "Temporização da MAU",se alguma, mais o tamanho da carga útil atual.
O valor do bit "B3P" no "Campo de bit 2" determinase o "Campo de bit 3" está presente. O valor padrão paratodos bits no "Campo de bit 3" é 0. A Figura 12 ilustra umesquema exemplar do Campo de bit 3 do MPF. Bit "Tempo dedecodificação presente" (D3) : Se este bit for 1, o campo"Tempo de decodificação" de 32 bits é inserido após o "Campode bit 3" mas antes do campo "Tempo de apresentação". Bit"Tempo de apresentação presente" (P) : Se este bit for 1, ocampo "Tempo de apresentação" de 32 bits é inserido após ocampo "Tempo de decodificação" mas antes do campo "NPT". Bit"NPT presente" (N) : Se este bit for 1, o campo "NPT" de 64bits é inserido imediatamente após o campo "Tempo deapresentação". R6, R7, R8, R9: Para cada um desses bits queé ajustado para 1, o receptor assume que um campo de 32 bitsfoi adicionado entre o campo "NPT" e o campo "Extensão". 0significado desses campos de 32 bits não é definido nesterelatório. Um receptor que não conhece o significado doscampos de 32 bits, os ignora.Bit "Extensão presente" (X): Se este bit for 1, umcampo "Extensão" de tamanho variável é inserido após o campo"NPT". "Tempo de decodificação": um campo de 32 bits. Estecampo especifica o tempo de decodificação da MAU. Quando oRTP é usado, o campo especifica o tempo de decodificação daMAU usando as mesmas unidades de tempo que são usadas para ocampo "Carimbo horário" no cabeçalho de RTP. "Tempo deapresentação": um campo de 32 bits. Este campo especifica otempo de apresentação da MAU. Campo "NPT": Um carimbohorário de 64 bits. O campo NPT especifica a posição nalinha de tempo de tempo de execução normal para a qual a MAUpertence.
A Figura 13 ilustra um esquema exemplar do campode extensão de um cabeçalho de MPF, de acordo com umamodalidade. O campo "Extensão" inclui uma ou mais coleçõesde campos. A Figura 13 ilustra o esquema dos campos contidoem uma tal coleção. Bit "L": Se este bit for "1", esta é aúltima coleção de campos "Extensão". Se o bit for 0, o fimdo campo "Dados de extensão" é seguido por pelo menos umamais coleção de campos "Extensão".
"Tipo de extensão": Um campo de 7 bits que é usadopara identificar os conteúdos do campo "Dados de extensão".
Adicionalmente, os valores 0 a 127 são reservados para usofuturo. "Comprimento de extensão": Um número de 8 bits dandoo tamanho, em bytes do campo "Dados de extensão" que aparecediretamente seguindo este campo. "Dados de extensão": campode comprimento variável. O tamanho deste campo é dado pelocampo "Comprimento de extensão".Os campos no campo "Extensão" possuem os valoresseguintes quando a extensão de vetor de inicialização éusada.
. "Tipo de extensão": É 2.
. "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, a ser usada como parte do vetor de inicialização paraa MAU atual. Quando esta extensão está presente, a unidadede criptografia é uma MAU completa. Se a MAU estiverfragmentada em múltiplas cargas úteis, a extensão de vetorde inicialização está presente somente na primeira cargaútil.
Os campos no campo "Extensão" possuem os valoresseguintes quando a extensão de 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 identifica a chave de decriptografia para usarpara decriptografar a carga útil atual.
A extensão de ID de chave permanece efetiva atéser substituída por uma diferente extensão de ID de chave.Portanto, a extensão é somente usada quando uma carga útilrequer o uso de uma chave de decriptograf ia que é diferenteda chave de decriptografia da carga útil anterior. Noentanto, se a carga útil anterior estava contida em umpacote de transporte que foi perdido, o receptor pode nãoestar ciente de que uma alteração de chave de decriptografiaé necessária. Se uma carga útil é decriptografada com achave errada, e esta situação não é detectada, pode levar aartefatos de renderização indesejáveis.
Uma abordagem para reduzir a severidade desteproblema é especificar a extensão de ID de chave para aprimeira carga útil de toda MAU que é um ponto desincronização. Esta é uma boa solução se for conhecido queuma MAU perdida irá forçar o receptor a descartar todas MAUaté que ele receba a próxima MAU de ponto de sincronização.Uma solução mais conservadora é especificar a extensão de IDde chave para a primeira carga útil em cada pacote detransporte de múltipla carga útil. Esta solução é robustacontra perda de pacote, uma vez que cargas úteisinterdependentes são todas contidas dentro de um únicopacote de transporte.
Quando os cabeçalhos de video MPEG estãopresentes, eles precedem o quadro subseqüente.
Especificamente:
.Um MPEG Vídeo_Sequence_Header, quando presente,está no inicio da MAU.
.Um MPEG GOP_Header, quando presente, está noinicio da MAU, ou segue um Vídeo_Sequence_Header.
.Um MPEG Picture_Header, quando presente, está noinicio de uma MAU, ou segue um GOP_Header.
Diferente de RFC 2250, se uma MAU contendo video éfragmentada, não existe exigência para realizar fragmentaçãoem um limite de fatia.As MAU podem ser fragmentadas em múltiplos pacotesde transporte por diferentes razões. Por exemplo, uma MAUpode ser fragmentada quando restrições de tamanho do pacotede transporte existem e quando existem diferenças nosparâmetros de criptografia para partes especificas da MAU.
Quando os campos de cabeçalho de RTP são interpretados, ocampo "Carimbo horário" no cabeçalho de RTP é ajustado paraPTS da amostra com uma precisão de 90 kHz, e o campo "Tipode carga útil" (PT) é ajustado de acordo com mecanismos denegociaçã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 envio" é opcional, apresença do campo "Correspondência" é opcional, e o bit"Campo de bit 2 presente" (B2P) é ajustado caso a carga útilcontenha uma parte de uma MAU que é criptografada, ou umfragmento de uma MAU que é criptografado.
Tendo em vista o exposto acima, o MPF permite queuma única MAU seja criptografada de acordo com diferentesparâmetros de criptografia. Isto inclui a capacidade parater fragmentos de uma única MAU que são criptografadosenquanto outros podem ser deixados sem criptografia. Em taiscasos, uma MAU pode ser fragmentada em múltiplas cargasúteis, cada com diferentes parâmetros de criptografia. Porexemplo, uma MAU ou um fragmento de uma MAU que écriptografada possui valores e campos ajustados de acordocom o seguinte critério:
. O bit "Campo de bit 2 presente" (B2P) na seçãode informação de pacote é ajustado para 1, para indicar queum "Campo de bit 2" está presente.
O bit "Criptografia" (E) na seção depropriedades da MAU é ajustado para 1, para indicar que acarga útil é criptografada.
O bit "Extensão presente" (X) na seção
"Temporização da MAU" é ajustado para 1, para indicar apresença de campos de extensão.
Uma extensão "Vetor de inicialização" éincluída. Os valores seguintes são ajustados:
O "Tipo de extensão" é ajustado para 2.
O "Comprimento de extensão" é ajustado para 8(significando 64 bits) se o campo "Dados de extensão" contémsomente uma ID de segmento de dados, ou 16 (significando 128bits) se o campo "Dados de extensão" contém ambas ID desegmento de dados e ID de bloco.
Os "Dados de extensão" são ajustados com o valorda ID de segmento de dados como descrito acima caso a ID debloco inicial seja zero. Se a ID de bloco inicial fordiferente de zero, então os "Dados de extensão" sãoajustados para a ID de segmento de dados seguida pela ID debloco inicial.
Esta extensão é incluída para cada carga útilcriptografada de uma MAU.
Uma extensão "ID de chave" é incluída. Osseguintes valores são ajustados:
. O "Tipo de extensão" é ajustado para 3.
. O "Comprimento de extensão" é ajustado para 16(significando 128 bits).. Os "Dados de extensão" são ajustados com o valorde ID de chave a partir da licença que corresponde a essaMAU.
. As extensões de "Vetor de inicialização" e "IDde chave" são incluídas para a primeira carga útil de umanova MAU em cada pacote de transporte de múltipla carga útilque contém múltiplas MAU. Isto assegura que um receptorsaiba sobre a ID de chave atual mesmo se alguns pacotes detransporte forem perdidos.
A seção Propriedades da MAU é interpretada comosegue:
. O bit "Ponto de sincronização" (S) é ajustadoquando a MAU contém um quadro I de vídeo ou um quadro deáudio.
. O bit "Descontinuidade" (Dl) é ajustado quandouma ou mais MAU estão faltando. Por exemplo, quando quadrosde vídeo foram descontinuados por um - tradutor dedescontinuação de quadro.
A utilização do bit "Descontinuável" (D2) éopcional. Definir em que casos ele deveria ser usado estáfora do escopo deste relatório.
. 0 bit "Criptografia" (E) é ajustado em caso acarga útil contenha uma parte de uma MAU que écriptografada, ou um fragmento de uma MAU que écriptografado.
A seção Temporizaçã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) é ajustado quandoum ou mais cabeçalhos de extensão estão presentes.
Procedimento Exemplar
A Figura 14 ilustra um procedimento exemplar 1400para proteger conteúdo de ES, de acordo com uma modalidade.Para fins de ilustração exemplar, operações de procedimento1400 são realizadas por um ou mais de um módulo de proteçãode ES 112 da Figura 1, um módulo de mapeamento 114, módulode embaralhamento de fluxo de transporte 210 da Figura 2,e/ou um módulo de empacotamento e demultiplexação 212.Várias mudanças e modificações serão aparentes àquelesversados na técnica a partir da presente descrição,incluindo mudanças e modificações na ordem das ações.
Com referência à Figura 14, no bloco 1405, fluxoselementares (ES) são recebidos ou de outra forma acessadospor um dispositivo de computação 102 ou fonte de conteúdo202. Os ES acessados podem ser independentes de um fluxo detransporte, ou transportados por um fluxo de transporte. Nobloco 1410, o procedimento 1400 protege partes da MAU do ES.Em uma implementação, essas operações de proteção sãorealizadas independente de embaralhamento comum. Em outraimplementação, essas operações de proteção são realizadasusando embaralhamento comum, por exemplo, quandoembaralhando de forma comum um fluxo de transporte. No bloco1415, se um fluxo de transporte for acessado no bloco 1405,o fluxo de transporte é demultiplexado em ES tal quecriptografia original é mantida. Operações dedemultiplexação do módulo 212 ilustram um componenteexemplar para realizar operações de demultiplexação de fluxode transporte.
No bloco 1420, o procedimento 1400 mapeia ESprotegidos para o formato de carga útil de MAU (MPF). Mapearcada MAU para o MPF provê um consumidor de midia que recebepacotes de transporte encapsulando os ES mapeados cominformação suficiente para permitir que o consumidor demidia processe cada ES independentemente de qualquer outroES, e processe cada MAU independentemente de qualquer outraMAU. No bloco 1430, o procedimento 1400 encapsula os ESmapeados para o MPF em um protocolo de transporte. Em umaimplementação, o protocolo de transporte é o protocolo detransporte em tempo real (RTP). No bloco 1440, oprocedimento 1400 comunica pacotes de transporte com base noprotocolo de transporte para um consumidor de midia paraprocessamento. Tal processamento, que inclui decriptografia,permite que o consumidor de midia experimente os dados decarga útil contidos nos pacotes de transporte.
Conclusão
Embora proteger conteúdo de ES foi descrito emlinguagem especifica para características estruturais e/ouações e operações metodológicas, deve ser entendido queimplementações definidas nas reivindicações em anexo nãoestão limitadas às características específicas ou açõesdescritas. Ao invés disso, as operações e característicasespecificas são descritas como formas exemplares deimplementar a matéria reivindicada.
Claims (20)
1. Método implementado por computador,CARACTERIZADO por compreender:identificar unidades de acesso de mídia (MAU) deconteúdo de fluxo elementar;para cada MAU das MAU, a MAU compreendendo um oumais segmentos de dados representando um único quadro deáudio ou vídeo:selecionar limites de criptografia com base nos umou mais segmentos de dados para proteção do único quadro devídeo ou áudio e cabeçalhos associados; eproteger a MAU como segue:criptografar partes da MAU com base nos limites decriptografia;mapear a MAU para um formato de carga útil de MAU;eonde o formato de carga útil de MAU provêprocessamento do fluxo elementar independente de qualquerdiferente dos fluxos elementares, e provê processamento daMAU independente de qualquer outra MAU.
2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o conteúdo de fluxo elementaré transportado por um fluxo de transporte, e onde protegeradicionalmente compreende embaralhar comumente o fluxo detransporte tal que uns respectivos dos segmentos de dadosque compreendem uma MAU das MAU são ou completamentecriptografados ou completamente não criptografados.
3. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que proteger adicionalmentecompreende criptografar uns separados dos um ou maissegmentos de dados com padrão de criptografia avançada emmodo de contador.
4. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que uma parte da MAU é deixadasem criptografia.
5. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que mapear a MAU adicionalmentecompreende fragmentar a MAU através de cargas úteis deprotocolo de transporte múltiplos.
6. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que mapear a MAU adicionalmentecompreende associar múltiplas cargas úteis para a MAU em umúnico pacote de protocolo de transporte.
7. Método, de acordo com a reivindicação 1,CARACTERIZADO adicionalmente pelo fato de que compreende:associar múltiplas cargas úteis para a MAU em umúnico pacote de protocolo de transporte; eonde duas ou mais das múltiplas cargas úteispossuem diferentes parâmetros de criptografia respectivos.
8. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o formato de carga útil deMAU compreende informação especifica de pacote associada comtodas as MAU em um pacote de protocolo de transporte.
9. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o formato de carga útil deMAU compreende:uma seção de propriedades de MAU para descreveruma MAU particular; ese a MAU for fragmentada, a seção de propriedadesinclui informação para permitir que um receptor analise aMAU quando uma parte fragmentada da MAU é perdida.
10. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o formato de carga útil deMAU compreende uma seção de temporização de MAU para proverinformação sobre os carimbos horários associados com a MAU.
11. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a informação compreende umalinha do tempo de tempo de execução normal (NPT) associadacom a MAU, o NPT para auxiliar especificação, por umreceptor, de uma posição para procurar dentro de umaapresentação.
12. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a informação compreende umtempo de apresentação indicando quando o receptor deveapresentar conteúdo da MAU.
13. Método, de acordo com a reivindicação 12,CARACTERIZADO pelo fato de que o tempo de apresentaçãoincrementa em uma taxa em tempo real para permitir que umdecodificador decodifique a MAU sem saber que uma execuçãocom artificio é usada.
14. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que proteger adicionalmentecompreende:analisar um fluxo de transporte para determinarpartes do fluxo de transporte que devem passar nãocriptografadas ;onde proteger adicionalmente compreende preparar ofluxo de transporte para processamento que desvia de partesembaralhadas comumente do fluxo de transporte.
15. Método implementado por computador,CARACTERIZADO por compreender:receber fluxos elementares, cada fluxo elementar(ES) sendo representado com múltiplas unidades de acesso demídia (MAU), cada MAU correspondendo a um único quadro deáudio ou vídeo do ES, cada fluxo elementar sendo mapeadopara um protocolo de transporte que encapsula um formato decarga útil de MAU (MPF); eprocessar o fluxo de transporte, o MPF permitindo15 que cada ES seja processado independente de qualquer outroES, e cada MAU seja processada independente de qualqueroutra MAU.
16. Método, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que o protocolo de transporte éprotocolo de transporte em tempo real (RTP) .
17. Método, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que uma parte de uma MAU das MAUé deixada sem criptografia.
18. Método, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que uma MAU das MAU é fragmentadaatravés de múltiplas cargas úteis de protocolo detransporte, ou onde múltiplas cargas úteis para a MAU estãoem um único pacote de protocolo de transporte.
19. Método, de acordo com a reivindicação 18,CARACTERIZADO pelo fato de que duas ou mais das múltiplascargas úteis possuem diferentes parâmetros de criptografiarespectivos.
20. Dispositivo de computação, CARACTERIZADO porcompreender:um dispositivo de identificação para identificarunidades de acesso de midia (MAU) de conteúdo de fluxoelementar;para cada MAU das MAU, a MAU compreendendo um oumais segmentos de dados representando um único quadro deáudio ou video:um dispositivo de seleção para selecionar limitesde criptografia com base nos um ou mais segmentos de dadospara proteção do único quadro de video ou áudio e cabeçalhosassociados; eum dispositivo de proteção para proteger a MAUcomo segue:um dispositivo de criptografia para criptografarpartes da MAU com base nos limites de criptografia;um dispositivo de mapeamento para mapear a MAUpara um formato de carga útil de MAU; eonde o formato de carga útil de MAU provêprocessamento do fluxo elementar independente de qualquerdiferente dos fluxos elementares, e provê processamento daMAU independente de qualquer outra MAU.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/202.828 | 2005-08-12 | ||
| US11/202,828 US20060184790A1 (en) | 2004-03-26 | 2005-08-12 | Protecting elementary stream content |
| PCT/US2006/031556 WO2007022038A2 (en) | 2005-08-12 | 2006-08-10 | Protecting elementary stream content |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0614675A2 true BRPI0614675A2 (pt) | 2011-04-12 |
Family
ID=37758250
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0614675-9A BRPI0614675A2 (pt) | 2005-08-12 | 2006-08-10 | protegendo conteúdo de fluxo elementar |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20060184790A1 (pt) |
| EP (1) | EP1913776A4 (pt) |
| JP (1) | JP2009505516A (pt) |
| KR (1) | KR20080033983A (pt) |
| CN (1) | CN101243687A (pt) |
| BR (1) | BRPI0614675A2 (pt) |
| WO (1) | WO2007022038A2 (pt) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210153156A1 (en) * | 2014-03-24 | 2021-05-20 | Imagination Technologies Limited | High definition timing synchronisation function |
Families Citing this family (46)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7370212B2 (en) | 2003-02-25 | 2008-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
| US7483532B2 (en) * | 2003-07-03 | 2009-01-27 | Microsoft Corporation | RTP payload format |
| US8438645B2 (en) | 2005-04-27 | 2013-05-07 | Microsoft Corporation | Secure clock with grace periods |
| US8725646B2 (en) | 2005-04-15 | 2014-05-13 | Microsoft Corporation | Output protection levels |
| US20060265758A1 (en) | 2005-05-20 | 2006-11-23 | Microsoft Corporation | Extensible media rights |
| US7684566B2 (en) | 2005-05-27 | 2010-03-23 | Microsoft Corporation | Encryption scheme for streamed multimedia content protected by rights management system |
| US7769880B2 (en) * | 2005-07-07 | 2010-08-03 | Microsoft Corporation | Carrying protected content using a control protocol for streaming and a transport protocol |
| US7561696B2 (en) * | 2005-07-12 | 2009-07-14 | Microsoft Corporation | Delivering policy updates for protected content |
| US8321690B2 (en) * | 2005-08-11 | 2012-11-27 | Microsoft Corporation | Protecting digital media of various content types |
| US7634816B2 (en) | 2005-08-11 | 2009-12-15 | Microsoft Corporation | Revocation information management |
| US7720096B2 (en) * | 2005-10-13 | 2010-05-18 | Microsoft Corporation | RTP payload format for VC-1 |
| KR100846787B1 (ko) * | 2006-02-15 | 2008-07-16 | 삼성전자주식회사 | 트랜스포트 스트림을 임포트하는 방법 및 장치 |
| US7961878B2 (en) | 2007-10-15 | 2011-06-14 | Adobe Systems Incorporated | Imparting cryptographic information in network communications |
| US7974411B2 (en) * | 2008-01-31 | 2011-07-05 | International Business Machines Corporation | Method for protecting audio content |
| US7978853B2 (en) * | 2008-01-31 | 2011-07-12 | International Business Machines Corporation | System and computer program product for protecting audio content |
| WO2009104869A1 (en) * | 2008-02-20 | 2009-08-27 | Electronics And Telecommunications Research Institute | Method and apparatus for svc video and aac audio synchronization using npt |
| KR100916505B1 (ko) * | 2008-02-20 | 2009-09-08 | 한국전자통신연구원 | 정상 재생 타임을 이용한 스케일러블 비디오 코딩 정보와어드밴스드 오디오 코딩 정보의 동기화 지원 방법 및 장치 |
| US8565083B2 (en) * | 2008-07-25 | 2013-10-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Thinning of packet-switched video data |
| US8051287B2 (en) | 2008-10-15 | 2011-11-01 | Adobe Systems Incorporated | Imparting real-time priority-based network communications in an encrypted communication session |
| WO2010071947A1 (en) * | 2008-12-24 | 2010-07-01 | The Commonwealth Of Australia | Digital video guard |
| EP2242273A1 (en) * | 2009-04-14 | 2010-10-20 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Transmission scheme for text-based information |
| JP2010268092A (ja) * | 2009-05-13 | 2010-11-25 | Sony Corp | 送信装置および送信方法、受信装置および受信方法、並びにプログラム |
| JP5463747B2 (ja) * | 2009-06-15 | 2014-04-09 | ソニー株式会社 | 受信装置、送信装置、通信システム、表示制御方法、プログラム、及びデータ構造 |
| US8638929B2 (en) * | 2009-11-30 | 2014-01-28 | Motorola Mobility Llc | System and method for encrypting and decrypting data |
| JP5512038B2 (ja) * | 2010-04-20 | 2014-06-04 | サムスン エレクトロニクス カンパニー リミテッド | メディアデータを送受信するためのインターフェース装置及び方法 |
| CN102469344B (zh) * | 2010-11-16 | 2013-10-09 | 腾讯科技（深圳）有限公司 | 一种视频码流加、解密方法、装置及通信、存储终端 |
| CN102622541B (zh) * | 2010-12-29 | 2016-02-24 | 奥多比公司 | 加密及解密的系统和方法 |
| US8938619B2 (en) * | 2010-12-29 | 2015-01-20 | Adobe Systems Incorporated | System and method for decrypting content samples including distinct encryption chains |
| US8930446B2 (en) | 2011-01-05 | 2015-01-06 | Motorola Mobility Llc | Altering transcoding priority |
| KR20120084237A (ko) * | 2011-01-19 | 2012-07-27 | 삼성전자주식회사 | 엠엠티(ｍｍｔ)에서 엠엠티 인캡슐레이터를 전송하는 방법 |
| KR101920439B1 (ko) * | 2011-04-28 | 2019-02-14 | 삼성전자주식회사 | 공용 인터페이스를 통해 수신 제한 모듈로 암호화된 데이터를 전송하기 위한 데이터 전송 장치 및 그에 적용되는 방법, 수신 제한 모듈 그리고 시스템. |
| KR20120138604A (ko) | 2011-06-14 | 2012-12-26 | 삼성전자주식회사 | 멀티미디어 시스템에서 복합 미디어 컨텐츠를 송수신하는 방법 및 장치 |
| US9088805B2 (en) * | 2012-02-08 | 2015-07-21 | Vixs Systems, Inc. | Encrypted memory device and methods for use therewith |
| US9015468B2 (en) * | 2012-04-26 | 2015-04-21 | Futurewei Technologies, Inc. | System and method for signaling segment encryption and key derivation for adaptive streaming |
| KR101603136B1 (ko) * | 2012-04-27 | 2016-03-14 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 템플릿 모드에서의 짧은 암호 사용기간의 지원 |
| KR102147475B1 (ko) * | 2012-07-11 | 2020-08-26 | 한국전자통신연구원 | Mpeg 데이터를 처리하는 방법 및 시스템 |
| WO2014010894A1 (ko) * | 2012-07-11 | 2014-01-16 | 한국전자통신연구원 | Mpeg 데이터의 랜덤 억세스를 지원하는 방법 및 시스템 |
| US20140215120A1 (en) * | 2013-01-30 | 2014-07-31 | Inmar, Inc. | System, method and computer program product for generating chronologically ordered globally unique identifiers |
| CN109905748B (zh) * | 2013-09-20 | 2022-05-10 | 松下电器（美国）知识产权公司 | 图像编码方法及装置、图像解码方法及装置 |
| JP6268066B2 (ja) | 2013-09-20 | 2018-01-24 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 送信方法、受信方法、送信装置及び受信装置 |
| WO2015102394A1 (en) | 2014-01-02 | 2015-07-09 | Lg Electronics Inc. | Broadcast transmission device and operating method thereof, and broadcast reception device and operating method thereof |
| EP3133817A4 (en) * | 2014-04-18 | 2017-11-15 | LG Electronics Inc. | Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, broadcast signal transmitting method and broadcast signal receiving method |
| EP3157260B1 (en) * | 2014-06-10 | 2020-07-29 | Sony Corporation | Transmission apparatus, transmission method and reception apparatus |
| EP3134995B1 (en) * | 2014-08-07 | 2021-12-22 | DivX, LLC | Systems and methods for protecting elementary bitstreams incorporating independently encoded tiles |
| US9596285B2 (en) * | 2014-09-11 | 2017-03-14 | Harman International Industries, Incorporated | Methods and systems for AVB networks |
| US20170094329A1 (en) * | 2015-09-25 | 2017-03-30 | Comcast Cable Communications, Llc | Coordinating Content Segmentation |
Family Cites Families (22)
| 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 |
| EP1034656A2 (en) * | 1998-06-11 | 2000-09-13 | Koninklijke Philips Electronics N.V. | Trick play signal generation for a digital video recorder |
| 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 |
| 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 |
| 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 |
| 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 |
| WO2001082610A1 (en) * | 2000-04-21 | 2001-11-01 | Sony Corporation | Information processing apparatus and method, program, and recorded medium |
| JP2002197794A (ja) * | 2000-12-25 | 2002-07-12 | Toshiba Corp | 音声映像データ同期再生方法 |
| US7260215B2 (en) * | 2001-09-04 | 2007-08-21 | Portauthority Technologies Inc. | Method for encryption in an un-trusted environment |
| JP2003115830A (ja) | 2001-10-03 | 2003-04-18 | Victor Co Of Japan Ltd | 情報記録装置及び情報記録再生装置 |
| 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 |
| US7702101B2 (en) * | 2002-07-09 | 2010-04-20 | Kaleidescape, Inc. | Secure presentation of media streams in response to encrypted digital content |
| US8015584B2 (en) * | 2002-10-18 | 2011-09-06 | Seachange International, Inc. | Delivering interactive content to a remote subscriber |
| AU2003295519A1 (en) * | 2002-11-13 | 2004-06-03 | 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 |
| JP4336957B2 (ja) * | 2003-09-30 | 2009-09-30 | 日本電気株式会社 | トランスポートストリームの暗号化装置及び編集装置並びにこれらの方法 |
-
2005
- 2005-08-12 US US11/202,828 patent/US20060184790A1/en not_active Abandoned
-
2006
- 2006-08-10 WO PCT/US2006/031556 patent/WO2007022038A2/en active Application Filing
- 2006-08-10 BR BRPI0614675-9A patent/BRPI0614675A2/pt not_active Application Discontinuation
- 2006-08-10 JP JP2008526267A patent/JP2009505516A/ja not_active Withdrawn
- 2006-08-10 CN CNA200680029310XA patent/CN101243687A/zh active Pending
- 2006-08-10 KR KR1020087003438A patent/KR20080033983A/ko not_active Application Discontinuation
- 2006-08-10 EP EP20060813402 patent/EP1913776A4/en not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210153156A1 (en) * | 2014-03-24 | 2021-05-20 | Imagination Technologies Limited | High definition timing synchronisation function |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2007022038A3 (en) | 2007-05-24 |
| CN101243687A (zh) | 2008-08-13 |
| US20060184790A1 (en) | 2006-08-17 |
| JP2009505516A (ja) | 2009-02-05 |
| EP1913776A4 (en) | 2014-08-20 |
| WO2007022038A2 (en) | 2007-02-22 |
| KR20080033983A (ko) | 2008-04-17 |
| EP1913776A2 (en) | 2008-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0614675A2 (pt) | protegendo conteúdo de fluxo elementar | |
| BRPI0614765A2 (pt) | protegendo conteúdo de fluxo elementar | |
| Pantos et al. | HTTP live streaming | |
| US8135949B2 (en) | Digital content distribution | |
| US20030200176A1 (en) | Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient | |
| BR112015021917B1 (pt) | Aparelhos e métodos de transmissão e de recepção | |
| NO339940B1 (no) | Nyttedata-format under RTP (Real-time Transport Protocol) | |
| WO2017092434A1 (zh) | 音视频实时传输方法及装置、音视频实时播放方法及装置 | |
| WO2022127164A1 (zh) | 接口数据传输方法、装置、电子设备及存储介质 | |
| US20180341777A1 (en) | Mpeg transport frame synchronization | |
| TW201713095A (zh) | 在適應串流及傳輸串流中內容保護及修改檢測 | |
| US9160721B2 (en) | Information processing apparatus and information processing method | |
| KR100840200B1 (ko) | Ｈ.２６４ 형식의 동영상 파일의 보호를 위한패키징/언패키징 장치 및 그 방법 | |
| JP2008187691A (ja) | コンテンツ配信システム、及びコンテンツ配信方法 | |
| BRPI0920333B1 (pt) | método e aparelho para distribuição segura de dados audiovisuais encapsulados de acordo com uma pluralidade de protocolos de transporte | |
| May | RFC 8216: HTTP Live Streaming | |
| Downs et al. | RFC 6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B11A | Dismissal acc. art.33 of ipl - examination not requested within 36 months of filing | ||
| B11Y | Definitive dismissal - extension of time limit for request of examination expired [chapter 11.1.1 patent gazette] |