JP2009505516A - エレメンタリストリームコンテンツの保護 - Google Patents

エレメンタリストリームコンテンツの保護 Download PDF

Info

Publication number
JP2009505516A
JP2009505516A JP2008526267A JP2008526267A JP2009505516A JP 2009505516 A JP2009505516 A JP 2009505516A JP 2008526267 A JP2008526267 A JP 2008526267A JP 2008526267 A JP2008526267 A JP 2008526267A JP 2009505516 A JP2009505516 A JP 2009505516A
Authority
JP
Japan
Prior art keywords
mau
field
transport
bit
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2008526267A
Other languages
English (en)
Inventor
ヴァーディ,ガープラタップ
オリヴェイラ,エドュアルド・ピー
クレメッツ,アンダース・イー
プリチェット,サディアス・シー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2009505516A publication Critical patent/JP2009505516A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14Arrangements for conditional access to broadcast information or to broadcast-related services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic 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/065Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/36Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols with means for detecting characters not meant for transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing 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/234327Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • H04N21/23476Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405Processing 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/44055Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835Generation of protective data, e.g. certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/167Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12Details 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

エレメンタリストリームメディアコンテンツを保護することが説明される。一態様では、エレメンタリストリームコンテンツのメディアアクセスユニット(MAU)が識別される。それぞれのMAUは、単一のビデオまたはオーディオフレームを表す1つまたは複数のデータセグメントを含む。暗号境界は、MAU毎に選択される。暗号境界は、それぞれのMAUに関連付けられている1つまたは複数のデータセグメントに基づく。それぞれのMAUの一部が、対応する暗号境界に基づいて暗号化される。それぞれのMAUは、MAUペイロードフォーマットにマッピングされる。MAUペイロードフォーマットにより、メディアコンシューマは、どの異なるエレメンタリストリームとも無関係にエレメンタリストリームコンテンツに関連付けられているそれぞれのエレメンタリストリームを処理することができる。MAUペイロードフォーマットでも、メディアコンシューマは、他のどのMAUとも無関係にエレメンタリストリーム内のそれぞれのMAUを処理することができる。
【選択図】図1

Description

メディアセンターは、典型的には、メディアコンテンツを配送する保護されたトランスポートストリームから暗号化を除去し、トランスポートストリーム(TS)を逆多重化(demultiplex)してエレメンタリストリーム(ES)にし、その後、再暗号化し、ネットワーク接続を介してメディアサブスクライバ(コンシューマ、クライアントなど)に配信する。復号化されたコンテンツは、著作権侵害およびその他の機密保護違反に対し脆弱であるため、メディアセンターによるそのような復号化および再暗号化オペレーションは機密保護を危険に晒す可能性がある。「メディアコンテンツ」は、ビデオ、オーディオコンテンツ、画像、アニメーション、テキストなどの1つまたは複数を含みうる「コンテンツ」、および「メディア信号」と同義である。
セットトップボックス(STB)、デジタルメディア受信機(DMR)、およびパーソナルコンピュータ(PC)などのメディアサブスクライバは、典型的には、メディアセンター、またはコンテンツソースから保護されたメディアコンテンツを受信する。保護されたメディアコンテンツは、ネットワーク接続を介して伝送される、または記憶媒体からダウンロードされる、暗号化されたオーディオ/ビデオデータを含む。
暗号化されたメディアコンテンツを(例えば、インデックス作成のため)処理する場合、メディアサブスクライバは、典型的には、メディアコンテンツ保護を除去する(つまり、メディアンコンテンツを復号化する)必要がある。このような復号化オペレーションは、典型的には、かなりのデバイスリソースを消費し、デバイスの性能を低下させ、その結果、デバイスの応答性および機能性を損なう可能性がある。
この「発明の開示」では、以下の「発明を実施するための最良の形態」でさらに説明される簡素化された形式の概念の選択を導入する。この「発明の開示」は、請求されている主題の鍵となる特徴または本質的特徴を明示することを意図しておらず、また請求されている主題の範囲を確定する補助として使用されることも意図していない。
上記に照らして、エレメンタリストリームメディアコンテンツを保護することについて説明される。一態様では、ESコンテンツのメディアアクセスユニット(MAU)が識別される。それぞれのMAUは、単一のビデオまたはオーディオフレームを表す1つまたは複数のデータセグメントを含む。暗号境界は、MAU毎に選択される。暗号境界は、それぞれのMAUに関連付けられている1つまたは複数のデータセグメントに基づく。それぞれのMAUの一部が、対応する暗号境界に基づいて暗号化される。それぞれのMAUは、MAUペイロードフォーマットにマッピングされる。MAUペイロードフォーマットにより、メディアコンシューマは、どの異なるESとも無関係にESコンテンツに関連付けられているそれぞれのESを処理することができる。MAUペイロードフォーマットでも、メディアコンシューマは、他のどのMAUとも無関係にES内のそれぞれのMAUを処理することができる。
詳細な説明は、付属の図面を参照しつつ説明される。
概要
メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりESコンテンツを保護するシステムおよび方法が説明される。より具体的には、これらのシステムおよび方法では、ESのメディアアクセスユニット(MAU)の一部を(例えば、MPEG−2などを使用して)暗号化する。それぞれのMAUは、単一のビデオまたはオーディオフレーム(エレメンタリストリームフレーム)および関連するヘッダである。MAUは、1つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、コンテンツ暗号化パラメータの同じ集合が適用されるMAUの連続するセクションである。データセグメントは、完全に暗号化されているか、または完全に平文である(つまり、暗号化されていない)。ESは、TSに由来していない場合がある。しかし、これらのES保護オペレーションは、TSストリームに適用される共通スクランブルオペレーションと互換性を持つ。
TSが保護されたESコンテンツを含む場合、TSは、既存の暗号化を維持しながらESに逆多重化される(つまり、TSは、復号化されない)。ESは、MAUペイロードフォーマット(MPF)にマッピングされ、これにより、ESのMAUがトランスポートプロトコル(例えば、リアルタイムトランスポートプロトコル(RTP))の中にカプセル化され、その後PCおよびセットトップボックスなどのメディアコンシューマに伝達される。それぞれのMAUをMPFにマッピングすることで、他のESと無関係にそれぞれのESを処理(例えば、逆多重化、インデックス作成、格納など)し、他のMAUとは無関係にそれぞれのMAUを処理するのに十分な情報がメディアコンシューマに与えられる。これらの技術は、1つまたは複数のデータセグメントからなるMAU部分に暗号化を適用することによりESコンテンツを保護しない従来のシステムとは対照的である。
ESコンテンツを保護するシステムおよび方法のこれらの態様および他の態様について、図1から14を参照しつつさらに詳しく説明することにする。
例示的な装置
説明のため、また必要というわけではないが、パーソナルコンピュータなどのコンピューティングデバイスによって実行されるコンピュータ実行可能命令の一般的背景状況においてESコンテンツの保護について説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。これらのシステムおよび方法は、前記の文脈において説明されているが、以下で説明される活動およびオペレーションは、ハードウェアでも実装することができる。
図1は、ESコンテンツを保護する例示的なシステム100を示している。システム100は、汎用コンピューティングデバイス102を含む。コンピューティングデバイス102は、パーソナルコンピュータ、ラップトップ、サーバー、ハンドヘルドまたはモバイルコンピューティングデバイスなどのどれかのタイプのコンピューティングデバイスを表す。コンピューティングデバイス102は、コンピュータ可読媒体106に結合されたプロセッサ104を備える。コンピュータ可読媒体106は、コンピューティングデバイス102によってアクセス可能な媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体(例えば、読み取り専用メモリ(ROM)およびランダムアクセスメモリ(RAM))、取り外し可能および取り外し不可能媒体を含む。コンピュータ可読媒体106のRAM部分は、プロセッサ104から直接アクセス可能な、および/またはプロセッサ104によって現在操作されているプログラムモジュールおよびプログラムデータを格納する。
例えば、限定はしないが、コンピュータ可読媒体106は、プログラムモジュール108およびプログラムデータ110を格納する。例えば、プログラムモジュール108は、ES保護モジュール112、保護ESコンテンツマッピングモジュール114、および他のプログラムモジュール116(例えば、オペレーティングシステム)を含む。ES保護モジュール112は、メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりESコンテンツを保護する。より具体的には、ES保護モジュール112は、ESコンテンツ118を(例えば、MPEG−2などを使用して)暗号化して、保護されたESコンテンツ120を生成する。この目的のために、ES保護モジュール112は、ESを含むメディアアクセスユニット(MAU)の部分(つまり、データセグメント)に暗号化を適用する。一実装では、暗号化オペレーションは、カウンタモードの高度暗号化標準(AES)である。それぞれのMAUは、単一のビデオまたはオーディオフレーム(エレメンタリストリームフレーム)であり、これは、その後、ヘッダ(例えば、開始コードおよびパディングビット)と関連付けられる。それぞれのMAUは、1つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、ES保護モジュール112がコンテンツ暗号化パラメータの同じ集合を適用するMAUの連続するセクションである。ES保護モジュール112は、データセグメントを完全に暗号化するか、またはそのデータセグメントを完全に平文として残す。ESは、TSに由来していない場合がある。しかし、これらのES保護オペレーションは、TSストリームに適用される共通スクランブルオペレーションと互換性を持つ(例えば、「他のデータ」122を参照)。
保護ESコンテンツマッピングモジュール114(「マッピングモジュール114」)は、保護されたESコンテンツ120をMAUペイロードフォーマット(MPF)にマッピングし、トランスポートパケット124内にカプセル化する。MPFでは、MAUの一部分が暗号化されないまま渡せる(平文に残される)。また、MPFは、パーソナルコンピュータまたはセットトップボックス(例えば図2を参照)などのメディアコンシューマが他のESと無関係にそれぞれの保護されているES 120を処理し、他のMAUと無関係に保護されているES中のそれぞれのMAUを処理するのに十分な情報を提供する。MPFは、「トランスポートプロトコルカプセル化のための保護されているESのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル(RTP)に基づくパケットに対応する。
一実施形態では、ESコンテンツ(例えば、ESコンテンツ118)は、メディアコンテンツトランスポートストリームに由来しない。例えば、他の実施形態では、図2を参照しつつ以下で説明されるように、ESコンテンツはトランスポートストリームに由来する。さらに、例示的なシステム100は、ES保護モジュール112と同じコンピューティングデバイス内に実装されている保護ESコンテンツマッピングモジュール114を示しているが、マッピングモジュール114は、保護モジュール112を実装するコンピューティングデバイスと異なるコンピューティングデバイスに実装することができる。このような代替え実装は、図2に関して以下で説明されるが、保護モジュール112のオペレーションは、コンテンツソースにより実行され、マッピングモジュール114のオペレーションは、メディアセンターにより実行される。
例示的なシステム
図2は、一実施形態により、ESコンテンツがトランスポートストリームに由来する、ESコンテンツを保護する例示的なシステム200を示している。トランスポートストリームは、メディアコンテンツをカプセル化する。例えば、システム200は、ネットワーク206を介して1つまたは複数のメディアサブスクライバ208に結合されているコンテンツソース202およびメディアセンター204を含む。コンテンツソース100は、ビデオゲームサーバー、Webサイト、ビデオサーバー、ミュージックサーバー、ソフトウェアアーカイブ、データベース、テレビネットワークなどに関連付けることができる。コンテンツソース202のTSスクランブルモジュール210は、トランスポートストリームを暗号化する。一実装では、トランスポートストリーム暗号化210では、トランスポートストリームを共通スクランブルする。共通スクランブルにより、ストリームの暗号化された部分を復号化しなくても、暗号化されたトランスポートストリームを処理(例えば、逆多重化、インデックス作成など)することができる。TSスクランブルモジュール210は、図1のES保護モジュール112に関して上で説明されているように、モジュールの関連するオペレーションがTSストリームに適用される共通スクランブルオペレーションと互換性を有するので、トランスポートストリームに由来するESコンテンツを保護する。
メディアセンター204は、例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP)または他の標準的な通信プロトコルを使用して、コンテンツソース202に、直接またはネットワーク206を介して結合できる中央集中配置コンピューティングデバイスである。ネットワーク206の実施例は、IPネットワーク、ケーブルテレビ(CATV)ネットワーク、および直接放送衛星(DBS)ネットワークを含む。メディアセンター204は、逆多重化およびマッピングモジュール212を備える。モジュール212は、単一のコンピュータプログラムモジュールとして示されているが、任意の数のコンピュータプログラムモジュールにより実装することができる。プログラムモジュール212の逆多重化オペレーションは、TSの暗号化部分を復号化することなく、TSをそれぞれのESに逆多重化する。
プログラムモジュール212のマッピングオペレーションは、逆多重化された保護されているESコンテンツをMPFに、図1の保護ESコンテンツマッピングモジュール114の説明されているオペレーションによりマッピングし、その後、トランスポートパケットにカプセル化してメディアコンシューマに伝達する。上述のように、MPFを使用すると、(複数の)トランスポートパケットにカプセル化されたときに、MAUのデータセグメントを平文のままに残すことができる。また、MPFは、メディアサブスクライバ208が他のESと無関係に受け取った、保護されているESを処理し、他のMAUと無関係に保護されているES内のそれぞれの関連するMAUを処理するのに十分な情報を提供する。MPFは、「トランスポートプロトコルカプセル化のための保護されているESのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル(RTP)に基づくパケットに対応する。
メディアセンター204は、ネットワーク206上でカプセル化され保護されているESコンテンツを1つまたは複数のサブスクライバ208に伝達し、PC 214および/またはSTB 216は、メディアコンテンツを受信する。PC 214上で処理され、レンダリングされたメディアコンテンツは、PC 214に関連付けられているモニタに表示させることができ、STB 216上で処理され、レンダリングされたメディア信号は、テレビ(TV)218または類似の表示デバイス上に表示させることができる。一実装では、TV 218は、STB 216の機能が内蔵されている。
トランスポートストリーム共通スクランブル分析
一実装では、ESコンテンツは、トランスポートストリームにより配送される。このシナリオでは、コンテンツソース202のTSスクランブルモジュール210は、共通スクランブルを行うためにトランスポートストリームを分析する。特に、トランスポートストリームは、暗号化された後にトランスポートストリームに適用されうる少なくとも1つのプロセスに対するデータ要件に照らして分析される。プロセスの1つまたは複数に対応する統計モデルに基づいて決定がなされる場合、最も広範な(つまり、閾値)データ要件を有する特定のプロセスについて閾値データ要件を決定することができる。この分析は、トランスポートストリームのどの部分が暗号化されないまま通るかを決定するために実行される。
共通スクランブル分析は、ヘッダ情報を含むトランスポートストリーム内のパケットが暗号化されないまま通ることの確認を組み込むことができる。このようなパケットおよびヘッダ情報については、図6を参照しつつ以下で説明される。PESヘッダ情報の一部または「追加ヘッダデータ」の一部を含むパケットは、暗号化されずに通る。さらに、完全な、または部分的なストリームマークを含むパケットも、暗号化されずに通る。
Figure 2009505516
表1を参照すると、この実装において平文のまま残されるデータの量は、ストリームマークの長さに最大データペイロード長を加えた値に対応することがわかる。平文セクションは、ストリームマークの前から始まり、ストリームマークと最大データペイロード長とを組み合わせた長さ分の後のところで終わるが、ただし組み合わされた長さが、例えば、2つの連続するTSパケットペイロードの長さを超えない場合に限ることに留意されたい。例えば、送信機(例えば、図2のコンテンツソース202など)は、シーケンスヘッダを表すストリームマークに対し平文中に16から368バイトを残すことができる(ストリームマークに対する4バイトと最大データペイロード長に対する12バイト)。
また、ストリームマークが現在のMAUの始まりの近くに出現する場合に、前のMAUからのある量のデータを平文中に残すことも可能である。一実装において、これは、平文セクションの長さが368バイトを超えない場合に許容される。
トランスポートストリームの一部が暗号化されないまま通るので、他の代替え実施形態では、中に含まれるデータが、逆スクランブルなしでトランスポートストリームを処理するのに使用されない場合に共通スクランブルが適用されるフレームヘッダおよびPESヘッダを考慮する。
暗号化
図3は、カウンタモードで高度暗号化標準(AES)を使用してESメディアコンテンツを暗号化するオペレーションの例示的な態様を示すブロック図である。図3に関して以下で説明されるさまざまなデータおよびオペレーションは、図1のES保護モジュール112の例示的なオペレーションおよび図2のTSスクランブルモジュール210の例示的なオペレーションを表している。データセグメントは、ESを暗号化するときに、保護されるコンテンツのタイプに基づき異なる定義を有する場合があるが、任意の数のデータセグメントを含むMAUは、ビデオまたはオーディオの単一のフレームを表す。
図3を参照すると、カウンタモードのAESは、トランスポートストリームのそれぞれのデータセグメントに基づいて複数のバイトからなるストリームを生成する。バイトのストリームとコンテンツの平文部分のバイトとのXORを取り、暗号化されたコンテンツを作成する。キーストリーム生成器は、AESラウンドを使用して、キーストリームの16バイトブロックを一度に生成する。AESラウンドへの入力は、コンテンツ暗号化キー(KC)およびデータセグメントIDと新しいセグメント内のブロックIDとの128ビット連結である。キーストリーム生成器の出力とデータセグメントの対応するブロック(i)からのデータとのXORが、バイト毎に取られる。データセグメントが16バイトで均等に分割可能でない場合、最後のブロックからのデータセグメントの残りのバイトのみと、キーストリームとのXORが取られ、中の暗号化されたデータ集合について保持される。MAU、および関連するヘッダは、さらに多くのデータセグメントである。
図4は、保護されたESを配送するトランスポートストリーム内に挿入する例示的な暗号方式(「TAG」)パケットを示す。図4を参照すると、
● adaptation_field_controlビットは、10bに設定され(適応フィールドのみ、ペイロードなし)、したがって、連続カウンタを増分する必要はない。
● AFヘッダは、MPEG規格に準拠する4バイトを含む。
○ 第1バイト=適応フィールド長
○ 第2バイト=適応フィールド存在フラグ(プライベートデータ=0x02)
○ 第3バイト=プライベートデータ長(DRM長)
○ 第4バイト=バージョン番号(現在は、0x00)
● DrmGuidは、{B0AA4966−3B39−400A−AC35−44F41B46C96B}に設定されたGUIDを含む。
● base_counterは、続く暗号化されたパケットについてAESカウンタの再同期処理を行う。
● SMバイト(ストリームマーク)は、続くパケットが最初の数バイトが欠けている可能性のある、ストリームマークの先頭を含むことを示す。
○ SM=0−次のパケットは、PESヘッダの先頭またはPESヘッダ全体を配送する。
○ SM=1−次のパケットは、ストリームマークの先頭を含む。
○ SM=2−次のパケットは、第1バイト(00)が欠けている、ストリームマークの先頭を含む。
○ SM=3−次のパケットは、最初の2バイト(00 00)が欠けている、ストリームマークの先頭を含む。
○ SM=4−次のパケットは、最初の3バイト(00 00 01)が欠けている、ストリームマークの先頭を含む。
○ SM=その他−予約。
● Private_DRM_parametersは、対応するキーID値とともにキーID拡張集合を含む、データセグメント記述子を含む。データセグメントIDがTAGパケットのbase_counterセクション内に示されているので、AES 128初期化ベクトル拡張は、存在しない。
● パケットは、0xFFをパディングされる。
したがって、TAGパケットは、それぞれの保護されているPESユニットの前に挿入されるキー識別子(KID)を持つ単一のTSパケットである。この実装では、TAGパケットは、コンテンツがメディアコンシューマに配信されたときに一致するデジタル権利管理(DRM)ライセンスを取り出すために使用される。コンテンツ保護レイヤは、カウンタモードでAES 128ビットキーを含み、その場合次の要件が適用される。128ビットカウンタは、base_counter(MSB)とminor_counter(LSB)の2つの64ビットフィールドに分割される。base_counterおよびminor_counterは、上述のデータセグメントIDおよびブロックIDと同等である。TAGパケットは、トランスポートストリームの暗号化された部分で使用される暗号化アルゴリズムの識別を行い、復号化キーを推論するために権限のある暗号解読器に必要なデータを提供し、暗号化されないまま、または暗号化されて通るトランスポートストリームの部分を識別することができる。TAGパケットは、それぞれのプロセスに使用される暗号化されたストリームの部分を識別する他のデータを含むことができる(トリックモードまたはサムネイル抽出のための逆多重化またはインデックス作成)。さらに、TAGパケットは、多重化されたトランスポートストリームに従って挿入される。
TAGパケットは、トランスポートストリームのすべての暗号化された部分に対応する形で生成されうる。それとは別に、暗号方式パケットは、暗号化されたPESペイロードデータの個々のパケットまたはバイトに対応する形で生成されうる。そのため、TAGパケットは、トランスポートストリーム内のそれぞれのPESヘッダと対応する形で、またはトランスポートストリーム内の所定の数のPESヘッダに対応する形で、または他のプロセスについては暗号化されないまま通る所定のパターンのパケットに対応する形で生成されうる。
図5は、一実施形態により、送信機側でトランスポートストリーム内のESコンテンツを保護するオペレーションの例示的な流れを示している(ESコンテンツがトランスポートストリームにより配送されない場合と比べて)。以下のリストは、図5の態様を説明したものである。
● scr−この変数は、現在のTSパケットが共通スクランブルされる場合に「yes」に設定され、それ以外の場合には「no」に設定される。
● key_sync−この変数は、送信機がAESキーを更新する場合に「yes」に設定され、それ以外の場合には「no」に設定される。
● PID(13ビット)−選択されたエレメンタリストリームのPID値。
● base_counter−この64ビットフィールドは、送信機の存続期間全体にわたって送信機により一意に定義される。一実装では、ビット0から50は、セクションカウンタを表し、ビット51から63は、そのPIDについて予約されている。
● Section_counter(51ビット)−scr状態変数のそれぞれのnoからyesへの遷移に対してインクリメントされる循環カウンタ。
● minor_counter−16個のスクランブルされたバイトからなるそれぞれのブロックに対しインクリメントされる64ビットカウンタ。
● i−それぞれスクランブルされたバイトに対しインクリメントされる4ビットカウンタ。
● scramble16−AESKEY[base_counter | minor_counter]。
Replace AES Keyイベントが発生した後、送信機は、即座に、すべてのPIDをスクランブルすることを停止し、それぞれのPESコンポーネントと再同期するまで停止したままになる。この遷移により、同じプログラムからのすべてのPIDが同じキーでスクランブルされることが保証される。scrステータスを定義するときに、送信機は、以下の条件のどれかが適用される場合に、受信されたTSパケット毎に、scr状態変数を「no」に設定する。
● key_sync=yes
● TSパケットが、PESヘッダの全部または一部を含む。
● TSパケットが、以下の表に記載されているストリームマークの1つまたは複数の全部または一部を含む。ストリームマークは、上の表1に示されているように、MPEG開始コードとその続くデータペイロードからなる。
図6は、一実施形態による、例示的なトランスポートストリームを示している。送信機は、TAGパケットを平文中に残されているTSパケットの前に挿入する。図6に示されているように、以下の2つのシナリオが考えられる。ケースA:TAGパケットが、PESヘッダの全部または一部を含むパケットの前に挿入される。ケースB:TAGパケットが、ストリームマークの全部または一部を含むパケットの前に挿入される。
さらに、実施形態では、TAGパケットがトランスポートストリーム内に挿入されることを必要としない。復号化の時点までTAGパケットは必要ないため、復号化の時点にプロセッサにより受信される限り、TAGパケットは、プロセッサに帯域内または帯域外で(例えば、プライベートテーブルにより)送信することができる。それに加えて、TAGパケットは、その後帯域内または帯域外でプロセッサに送信されるコンテンツ利用ライセンスに送信されうる。
保護されているESのMAUペイロードフォーマットへのマッピング
保護されているESは、共通スクランブルされたトランスポートストリーム内のMAUのセクションが平文中に残されるようにMPFにマッピングされる。このマッピングにより、メディアコンシューマはそれぞれのMAUを独立に処理することができる。一実装では、コンテンツソース202などの送信機がこれらのマッピングオペレーションを実行する。
従来のRTPヘッダの構文は、RFC−3550において定義されており、また図11に示されている。RTPヘッダとともに、図1のシステム100および図2のシステム200は、保護されているESコンテンツ(例えば、図1の保護ESコンテンツ120)をMAUペイロードフォーマット(MPF)にマッピングする。しかし、マルチメディアプレゼンテーションにおけるすべてのメディアストリームが、同じMPFを使用する必要はなく、異なるペイロードフォーマットを使用することもできる。そこで、MAUがMPFにおいてどのようにカプセル化されるかについて説明する。
図7は、一実施形態による、MPFヘッダの例示的な高水準構造を例示している。ヘッダは、標準RTPヘッダに関して示されている。MPFヘッダは、送信機(例えば、図1のコンピュータ102および/または図2のメディアセンター)により、トランスポートパケット内のそれぞれのMAU、またはそのフラグメントの前に挿入される。図7に示されているように、この例示的な実装におけるMPFヘッダは、3つのセクションに分割される。それぞれのセクションは、1バイトビットフィールドから始まり、その後に1つまたは複数のオプションフィールドが続く。いくつかの場合において、MPFヘッダから、最大2つまでのセクションを丸ごと省くことができる。そのため、MPFヘッダは、1バイトと小さくすることができる。
MPFヘッダの後に、「ペイロード」が続く。ペイロードは、完全なMAU、またはそのフラグメントを含む。ペイロードは、部分的MAUを含み、複数のトランスポートパケット中の複数のペイロードにわたって大きなMAUを断片化(フラグメント化)することができる。トランスポートパケットのサイズにより許されれば、第1のペイロードの後に、MPFヘッダとペイロードの追加の対を続けることができる。
図7において「Packet Specific Info(パケット指定情報)」と呼ばれる、MPFヘッダの第1のセクションは、トランスポートパケット内のすべてのペイロードに固有の情報を含む。「Packet Specific Info」セクションは、RTPヘッダの終わりの直後に出現する、第1のMPFヘッダにおいて、それぞれのトランスポートパケット内に1回だけ含まれる。「MAU Properties(MAUプロパティ)」と呼ばれる第2のセクションは、ペイロードを説明する情報を含む。例えば、このセクションでは、ペイロードがビデオIフレームなどの同期点であるMAUを含むかどうかを指定し、さらに、ペイロードのサイズがどのように決定されるかも指定する。さらに、このセクションは、前のパケットが失われた場合にトランスポートパケットを受信機側で解析するために使用される情報を含む。これは、MAUが複数のトランスポートパケット上に断片化されている場合に有用である。
「MAU Timing(MAUタイミング)」と呼ばれる第3のセクションは、ペイロード中のMAUに関連付けられているさまざまなタイムスタンプに関する情報を提供する。例えば、このセクションでは、MAUのプレゼンテーション時間がどのように決定されるかを指定する。このセクションは、さらに、追加の情報をMPFヘッダに入れるための拡張機構も備える。
図8は、一実施形態による、図7のMPFヘッダの例示的な詳細レイアウトを示している。図8の3つのセクション802から806はそれぞれ、複数の個別ヘッダフィールドを備える。これらのフィールドは、図8にボックスとして示されている。これらのボックスの高さは、ヘッダフィールドの相対的サイズを示すものとなっている。しかし、図は、完全に縮尺通りには描かれておらず、「Extension(拡張)」フィールドは可変長サイズを有することに留意されたい。
図8を参照すると、3つのセクションのそれぞれの中の第1のヘッダフィールドは、ビットフィールドである。セクション内の他のヘッダフィールドは、そのセクションのビットフィールドにより示された場合にのみ存在する。いくつかの場合において、そのビットフィールドを含む、1つのセクション全体を省くことができる。パケット指定情報(Info)セクションは、「Bit Field 1(ビットフィールド1)」を含み、また図8に示されている他のフィールドのどれかも含みうる。同じトランスポートパケット内の追加のMPFヘッダは、「Bit Field 2(ビットフィールド2)」から始まり、「MAU Properties」セクションおよび「MAU Timing」セクション内にフィールドを備える。
可能な最も単純な場合には、トランスポートパケットは、単一の完全なMAUを含む。この場合、ヘッダフィールドのすべてを含めることが可能である。しかし、必要のないフィールドは省くことができる。MPFヘッダの3つのセクションのそれぞれは、もし存在する場合、そのセクション内のフィールドのどれが存在するかを示すビットフィールドを有する。
例えば、現在のペイロードの終わりに対するバイトオフセットを指定する「Offset(オフセット)」フィールドは、パケットが単一のペイロードを含む場合には必要ないが、それは、ペイロードの長さが、トランスポートパケットのサイズにより推論できるからである。「Bit Field 2」内の「OP」は、「Offset」フィールドが存在するかどうかを示す。「Bit Field 3(ビットフィールド3)」内のビットのすべてが0である場合、「Bit Field 3」それ自体を省くことができ、これは、「Bit Field 2」内の「B3P」を0に設定することにより示される。
複数のペイロードを単一のトランスポートパケット内にまとめることが可能である。これは、「グルーピング」と呼ばれる。「Offset」フィールドは、「グルーピング」の使用を示す。「Offset」フィールドが存在する場合、他のMPFヘッダおよび他のペイロードは、現在のペイロードの終わりの後から続くことができる。「Offset」フィールドは、「Offset」フィールド自体の終わりから数えた、現在のペイロードの終わりまでのバイトの個数を指定する。他のMPFヘッダが現在のペイロードの終わりの後に続くかどうかを判定するために、いくつかの実装において、「Offset」フィールドの値だけでなく、トランスポートパケットのサイズをも考慮する必要があり、またRTPがトランスポートプロトコルとして使用される場合に、もしあれば、RTPパディング領域のサイズも考慮する必要がある。
単一のMAUを分割して複数のペイロードに分けることができる。これは、「断片化」と呼ばれる。断片化は、MAUが単一のトランスポートパケット内に収まることのできるものの大きさを超えた場合に主に使用される。「Bit Field 2」内の「F」フィールドは、ペイロードが完全なMAUまたはそのフラグメントを含むかどうかを示す。
「MAU Timing」セクション内のフィールドは、MAUの第1のフラグメントを含むペイロードに対するMPFヘッダ内でのみ指定すべきである。これに対する唯一の例外は、「MAU Timing」セクション内の「Extension」フィールドが同じMAUの異なるフラグメントに対し異なる拡張を含む場合である。MAUが断片化された場合に、「Bit Field 2」内のビット「S」、「D1」、および「D2」は、第1のフラグメントを含むペイロードに対するMPFヘッダでのみ有意である。したがって、受信機(メディアコンシューマ)は、「F」フィールドの値が0または2の場合にこれらのビットを無視する。
この実装では、MAUは、大きすぎて単一のトランスポートパケットに収まらないというのでない限り断片化されない。この実装では、MAUのフラグメントは、単一のトランスポートパケットにおいて、他のMAUと、または他のMAUのフラグメントと組み合わされることはない。しかし、受信機は、そのまま、これらのケースも取り扱える。これの実施例は、図9に示されている。
図9は、一実施形態により、MPFを使用するリアルタイムトランスポートパケットという3つのパケットの例示的シーケンスを示している。この3つのトランスポートパケットは、4つのMAUからなるデータを配送する。第4のMAUは、第4のトランスポートパケット(図示せず)内で続けられる。図は、もし必要ならば、固定サイズのトランスポートパケットを作成するためにMAUの断片化をどのように使用できるかを示している。図からわかるように、MAU 2は、2つのトランスポートパケットにわたって断片化されている。第1のトランスポートパケットでは、MAU 2に対するMPFヘッダは、次のトランスポートパケット内でMUA 2が継続されることを指定する。(これは、「Bit Field 2」内の「F」フィールドを使用して知らされる)。
第2のトランスポートパケットは、「MAU Timing」フィールドを省いたMPFヘッダから始まるが、それは、MAU2に対する「MAU Timing」フィールドが、すでに、第1のトランスポートパケット内で指定されているからである。「MAU Properties」セクションの「Offset」フィールドは、MAU 3に対するペイロードフォーマットヘッダの先頭を見つけるために使用される。これにより、クライアントは、前のトランスポートパケットが失われたとしても、MAU 3を復号化することができる。同様に、図は、MAU 4が第2および第3のトランスポートパケット上にどのように断片化されるかを示している。しかし、MAU 4は、大きくて、追加のMAUを第3のトランスポートパケット内に挿入することができない。この実施例では、MAU 4は、図に示されていない、第4のトランスポートパケット内で続けられる。このような状況では、第3トランスポートパケットのペイロードフォーマットヘッダは、「Offset」フィールドを含む必要はなく、「MAU Properties」セクション全体を省くことが可能な場合がある。次いで、MPFヘッダの残り部分は、「Packet Specific Info」セクションのみを含み、単一のバイトと同じくらい小さくできる。
MAUが複数のペイロードに断片化される場合、それらのペイロードは、通常、別々のトランスポートパケットで配送される。しかし、このMPFでは、さらに、同じMAUに対する複数のペイロードを単一のトランスポートパケット内で配送することもできる。
トランスポートパケット内のペイロードがMAUのフラグメントを含む場合、これは、「Bit Field 2」内の「F」フィールドにより示される。
図10は、一実施形態により、単一のMAUが同じRTPパケット内の3つのフラグメントに分割されている一実施例を示している。この実施例では、第1のMPFヘッダ内の「F」フィールドは、1に設定され、第1のペイロードがMAUの第1のフラグメントを含むことを示す。「MAU Timing」セクションは、この第1のペイロードにしか存在しない。第2のMPFヘッダ内の「F」フィールドは、0に設定され、そのペイロードが、MAUの最初のフラグメントでも最後のフラグメントでもないフラグメントを含むことを示す。第3のMPFヘッダ内の「F」フィールドは、2に設定され、そのペイロードがMAUの最後のフラグメントを含むことを示す。
通常のRTPサンプリングクロックおよびウォールクロックに加えて、MPFは、これから説明する、いくつかの追加のタイムスタンプおよび時間の概念を示す。RTPヘッダは、パケット内のデータがサンプリングされた時間を指定する、単一のタイムスタンプを有する。このタイムスタンプは、ときには、サンプリングクロックとも呼ばれる。異なるメディアストリームに属すパケットのRTPタイムスタンプは、比較することができないことに留意されたい。なぜなら、サンプリングクロックは、異なるメディアストリームについては異なる周波数で動作する可能性があるからである。例えば、オーディオストリームのサンプリングクロックは44100Hzで動作するが、ビデオストリームのサンプリングクロックは、90000Hzで動作しうる。さらに、RFC−3550では、初期RTPタイムスタンプの値は、ランダムに選択されなければならないと規定している。実際、それぞれのメディアストリームは、それ専用の時系列を有する。本明細書では、それぞれのこのような時系列は、「メディア時系列」と呼ばれる。
RTPにより、異なるメディアストリームに対する時系列を「ウォールクロック」と呼ばれる基準クロックの時系列と同期させることができる。RTP送信機側では、受信機がサンプリングクロックとRTCP送信機レポートパケット内のウォールクロックとの間のマッピングを送信することによりこのような同期を取ることを許可する。メディアストリームが異なるサンプリングクロックを使用する場合があるため、メディアストリーム毎に異なるRTCP送信機レポートが送信されなければならない。
マッピングは、何らかの間隔で再び更新および送信され、これにより、受信機側は、ウォールクロックとサンプリングクロックとの間で発生しうるドリフトを補正することができる。クロックドリフトは、送信機のウォールクロックが受信機のウォールクロックに関してドリフトする場合には依然として問題となりうる。2つのクロックを同期させるために、例えば、NTPプロトコルを使用することが可能であろうが、RTP規格では、特定の同期方法を規定していない。ウォールクロックは、符号器から供給されることに留意されたい。RTP送信機および符号器が、別々の要素である場合、ウォールクロックは、典型的には、送信機側のどの物理的クロックとも無関係である。
このMPFは、通常再生時間(NPT)時系列と呼ばれる第3の時系列を使用する。NPT時系列は、主にRTPがメディアの「プレゼンテーション」を送信するために使用される場合に有用である。NPT時系列から得られるタイムスタンプは、ふつう、プレゼンテーションの先頭の0から始まる。NPTタイムスタンプは、特に、事前に記録されているプレゼンテーションを送信する場合に有用であるが、それは、タイムスタンプを使用すると受信機側がプレゼンテーション内で探索すべき位置をユーザーが指定するのを補助するからである。この場合、受信機が新しい位置をRTP送信機に伝達するための何らかの機構の存在を仮定する。
RTPは、マルチメディア会議アプリケーション向けに設計されていたため、RTP規格では、NPT時系列を規定しない。しかし、RTSP(ビデオオンデマンドアプリケーション用の制御プロトコル)などのRTPの上に構築された他のプロトコルは、NPT時系列の概念を含む。RTSPでは、制御プロトコルは、メディアストリーム毎にNPT時系列とメディア時系列との間のマッピングを行う。
MPFは、MAUに関連付けられているNPT時系列タイムスタンプを指定する機構を定義する。しかし、実用的であれば、RTSPによって定義されたものなどのメディア時系列とNPT時系列との間の帯域外マッピングは、MPFヘッダのオーバーヘッドを低減するので、好ましい場合がある。
すべてのRTP準拠システムは、タイムスタンプのラップアラウンドを処理する。典型的なクロック周波数90000Hzでは、RTPタイムスタンプは、ほぼ13時間おきにラップアラウンドする。しかし、RTP規格では、ランダムオフセットをサンプリングクロックに加えなければならないと規定しているため、受信機で生じる第1のラップアラウンドは、13時間よりも著しく短いものとなりうる。RTPタイムスタンプのラップアラウンドは、通常、合同演算を使用することにより処理される。合同演算が使用される場合、タイムスタンプは、通常、一方のタイムスタンプを他方のタイムスタンプから減算し、その結果が正であるか、または負であるかを観察することにより比較される。
MPFでは、それぞれのMAUは、「復号化時間」および「プレゼンテーション時間」を有する。復号化時間は、MAUが受信機の復号器に送られなければならない期限であり、プレゼンテーション時間は、MAUが受信機により提示(表示または再生)されなければならない時間である。時間は両方とも、メディア時系列に属する。ネットワークおよび復号器内の遅延が典型的にはRTP送信機側に知られていないため、受信機側では、復号化タイムスタンプまたはプレゼンテーションタイムスタンプの絶対値を使用しない。受信機側では、復号化タイムスタンプの対またはプレゼンテーションタイムスタンプの対の間の相対的差のみを考慮する。
ビデオコーデックが双方向ビデオフレームを生成する場合などいくつかの場合において、MAUは、提示される異なる順序で復号化することができる。この実装では、RTP送信機は、MAUを、それらが復号化されなければならない順序で送信する。
RTPヘッダ内の「Timestamp(タイムスタンプ)」フィールドは、トランスポートパケットを第1のMAUのプレゼンテーション時間にマッピングされる。トランスポートパケットは、復号化順序で送信されるため、連続するMAUのプレゼンテーション時間スタンプは、単調非減少とはなりえない。
MPFヘッダは、オプションの「Decode Time(復号化時間)」フィールドを含み、これは、ペイロード中のMAUの復号化時間を指定するために使用される。MPFヘッダは、さらに、「Presentation Time」フィールドを含み、これは、トランスポートパケットが複数のMAUを含む場合に、MAUのプレゼンテーション時間を指定するために使用される。単一のMAUのみがトランスポートパケットに含まれる場合、「Presentation Time(プレゼンテーション時間)」フィールドであるが、それは、「Timestamp」フィールドがパケット内の第1のMAUのそのフィールドの代替えとして使用されるからである。この実装では、「Decode Time」および「Presentation Time」の両方フィールドが、「Timestamp」フィールドと同じクロック分解能を使用して表される。
「トリックプレイ」という用語は、受信機が非リアルタイム速度でメディアンプレゼンテーションをレンダリングすることを意味する。トリックプレイの実施例は、プレゼンテーションの早送りおよび巻き戻しを含む。RTP送信機が、トリックプレイモードで送信している場合、それぞれのMAUに対する復号化タイムスタンプおよびプレゼンテーションタイムスタンプは、リアルタイム速度でインクリメントしなければならない。これにより、復号器は、トリックプレイが使用されることを知らずにMAUを復号化することができる。MPFヘッダ内の「Decode Time」および「Presentation Time」フィールドは、トリックプレイの影響を受けず、「NPT」フィールドは、存在する場合、影響を受けないということはない。例えば、メディアプレゼンテーションが巻き戻しされている場合、MAUの「Presentation Time」タイムスタンプフィールドは、増加するが、「NPT」フィールドの値は、減少する。
MPFヘッダ内の「NPT」フィールドでは、MAUが属する通常再生時間時系列内の位置を指定する。「NPT」フィールドが存在していない場合、受信機は、2つの時系列の間のマッピングが利用可能とした場合に、プレゼンテーション時間からMAUの通常再生時間を計算することができる。このマッピングを設定するさまざまなアプローチについて、以下で説明する。RTP送信機は、メディア時系列内のタイムスタンプにランダムオフセットを加えるので、プレゼンテーション時間タイムスタンプは、NPTタイムスタンプの直接的代替えとして使用されない。このランダムオフセットが受信機側に知られているとしても、メディア時系列タイムスタンプのラップアラウンドは、問題となる可能性がある。
これらの問題に対し考えられる解決策として、送信機側で帯域側機構を使用して通常再生時間時系列とメディア時系列との間のマッピングを行うという方法がある。このマッピングは、伝送の開始時に1回だけ、または必要に応じて繰り返し行うことも可能である。さらに、トリックプレイが可能であれば、送信機側でトリックプレイ速度を伝達する。例えば、プレゼンテーションが巻き戻しされている場合、トリックプレイ速度は負である。受信機では、トリックプレイ速度を使用して、プレゼンテーション時間が長くなると減少するNPTタイムスタンプを生成する。
マッピングが、伝送の始めに1回だけ行われる場合、受信機側で、通常再生時間時系列とウォールクロック時系列との間のマッピングを確立する。これは、通常、適切なRTCP送信機レポートパケットが受信されると直ちに可能になる。メディア時系列からのタイムスタンプは、ウォールクロック時系列に対してドリフトする可能性があるため、MAUのウォールクロック時間に基づいてそれぞれのMAUについてNPTタイムスタンプを計算することが好ましい。
RTSPプロトコルは、通常再生時間時系列と伝送の始めのメディア時系列との間のマッピングを行う制御プロトコルの一実施例である。複雑度とオーバーヘッドとの間の適当なトレードオフの関係をもたらす他の解決策では、同期点MAUでのみ「NPT」フィールドを含む。「NPT」フィールドは、通常再生時間時系列とプレゼンテーションまたはウォールクロック時系列との間のマッピングを確立するために使用される。非同期点MAUについては、受信機は、すでに確立されているマッピングを使用してNPTタイムスタンプを計算する。トリックプレイが使用される場合、送信機は、すべてのMAUについて「NPT」フィールドを含む。
MPFヘッダ内の「Send Time(伝送時間)」フィールドでは、トランスポートパケットの伝送時間を指定する。これは、トランスポートパケットのシーケンスが、一方のサーバーから第2のサーバーに転送される場合に有用と考えられる。第1のサーバーのみが、パケットに対する伝送スケジュールを計算する必要がある。第2のサーバーは、「Send Time」フィールドの値に基づいてトランスポートパケットを他のクライアントに転送する。トランスポートパケットをクライアントに転送するときに、「Send Time」フィールドを含んでいる必要はない。しかし、クライアントは、一連のパケット内の「Send Time」フィールドの値の差をパケット到着時間の差と突き合わせて比較することにより「Send Time」フィールドを使用して、ネットワークの混雑を検出することができる。「Send Time」フィールドでは、メディア時系列と同じユニットを使用する。
「Correspondence(対応)」フィールドは、ウォールクロック時系列と現在のメディア時系列との間のマッピングを規定する。RTPが転送プロトコルの場合、これは、RTCP送信機レポート内にもたらされるのと同じマッピングである。トランスポートパケット内にマッピングを含めることは、別のRTCPパケットを伝送するのよりも効率的である。これにより、送信機は、RTCP送信機レポートの頻度を下げ、そのまま、必要な頻度でマッピングを送信することができる。
図11は、参照を目的として標準的な12バイトRTPヘッダを例示している。図11を参照すると、
● 「Version」(V)フィールド:2ビット。このフィールドは、2に設定される。
● 「Padding」(P)ビット:このビットは、RTPパケットの末尾にパディングを加えるために使用される。
● 「Extension」(X)ビット:このビットは、RTPヘッダ拡張が存在している場合に1に設定される。RTPプロファイルで、ヘッダ拡張がどのように使用されるかが定義される。受信機は、RTPヘッダが非ゼロの「Extension」ビットを有している場合にヘッダ拡張を解析するか、またはスキップすることができる。
● 「Contributing Source」(CC)フィールド:4ビット。受信機は、RTPヘッダが非ゼロの「contributing source」フィールドを有している場合に寄与するソースのリストを正しく解析するか、またはスキップすることができる。
● 「Marker」(M)ビット:このビットは、トランスポートパケット内のペイロードが完全なMAUまたはMAUの最後のフラグメントを含む場合に1に設定される。
● 「Payload Type」(PT)フィールド:7ビット。RTPペイロードタイプの割り当ては、本明細書の範囲を外れている。これは、このペイロードフォーマットが使用されるか、または動的に帯域外に信号伝送される際に基づくRTPプロファイルにより指定される(例えば、SDPを使用して)。
● 「Sequence Number」フィールド:16ビット。このフィールドは、同じSSRC値とともにトランスポートパケットが送信される毎に1だけインクリメントされる数を含む。RTPシーケンス番号の初期値は、非RTP手段を通じてクライアントに伝達することができる。
● 「Timestamp」フィールド:32ビット。このフィールドでは、トランスポートパケットに含まれる第1のペイロードに適用されるタイムスタンプを指定する。デフォルトでは、このフィールドは、プレゼンテーション時間として解釈される。「Timestamp」フィールドのクロック周波数は、90kHzとすることが推奨される、つまり、分解能は、1/90000秒である。送信機および受信機は、非RTP手段を通じて異なるクロック周波数をネゴシエートすることができる。
● 「Synchronization Source」(SSRC)フィールド:32ビット。SSRCフィールドに対し同じ値を持つトランスポートパケットは、「Timestamp」フィールドに対する同じ時系列および「Sequence Number」フィールドに対する同じ数空間を共有する。
RTPヘッダの後に、MPFヘッダが続く。唯一の例外は、パディングしか含まないトランスポートパケットである。その場合、MPFヘッダは、存在しない。トランスポートパケットが、複数のMAUからのデータを含む場合、MPFヘッダは、それぞれのMAUの前、およびそれぞれの断片化された(部分的)MAUの前に現れる。したがって、このペイロードフォーマットを使用するトランスポートパケットは、1つまたは複数のMPFヘッダを含むことができる。MPFヘッダのレイアウトは、図7に示されている。MPFヘッダが標準12バイトRTPヘッダの直後に来る場合、これは、「Bit Field 1」という1バイトフィールドから始まり、その後に一連のオプションフィールドが続く。このヘッダの後に、ペイロードが続く。ペイロードは、完全なMAU、またはフラグメント(部分的)MAUのいずれかを含む。
第1のデータペイロードの後に、他のMPFヘッダが現れ、他のデータペイロードが続く。データペイロードの後に他のMPFヘッダを加えるプロセスは、複数回繰り返すことができる。「Bit Field 2」フィールドを持つ第1のデータペイロードに続くそれぞれのMPFヘッダ。
以下に、「Bit Field 1」フィールドのレイアウトを示す。
● 「Send Time Present」(ST)ビット:このビットが1の場合、32ビットの「Send Time」フィールドが、「Bit Field 1」フィールドの末尾の直後に挿入される。
● 「Correspondence Present」(CP)ビット:このビットが1の場合、96ビットの「Correspondence」フィールドが、「Send Time」フィールドの後に挿入される。
● R1、R2、R3(それぞれ1ビット):1に設定されているこれらのビットのそれぞれについて、受信機側では、32ビットフィールドが「Correspondence」フィールドと「Bit Field 2」との間に追加されていると想定する。これらの32ビットフィールドの意味は、本明細書では定義されていない。32ビットフィールドの意味を認識しない受信機は、それらを無視する。
● R4、R5(それぞれ1ビット):将来使用するために予約されており、現在は、0に設定されている。
● 「Bit Field 2 Present」(B2P)ビット:このビットが1の場合、1バイトの「Bit Field 2」フィールドが、「Correspondence」フィールドの後に挿入される。
● 「Send Time」フィールド:32ビット。このフィールドは、RTPヘッダ内の「Timestamp」フィールドに使用されるのと同じ時間単位を使用して、トランスポートパケットの伝送時間を指定する。
● 「Correspondence」フィールド:96ビット。フィールドは、2つのタイムスタンプを含む。NTPフォーマットの64ビットウォールクロックタイムスタンプ、および32ビット復号化時間タイムスタンプ。2つのフィールドは、RFC−3550の6.4.1で定義されている、RTCP送信機レポートの「NTP timestamp」および「RTP timestamp」フィールドと同じようにして使用される。
「Bit Field 1」が存在する場合、「Bit Field 2」はオプションである。「Bit Field 1」の「B2P」ビットは、「Bit Field 2」が存在するかどうかを判定する。「Bit Field 2」のすべてのビットに対するデフォルト値は、0である。「Fragmentation」フィールド(F)は、データペイロードが部分的MAUを含むかどうかを示す。1つまたは複数のそのようなペイロードが組み合わされ、完全なMAUを再構成する。「F」フィールドは、さらに、ペイロードが、MAUの最初または最後のフラグメントを含むかどうかも示す。「S」、「D 1」、および「D2」ビット(以下)は、「F」フィールドの値が0または3の場合にのみ有効である。表2は、Fフィールド値の例示的な意味を示す。
Figure 2009505516
「Offset Present」ビット(OP):このビットが1の場合、16ビットの「Offset」フィールドが、「Bit Field 2」の直後に挿入される。「Offset」フィールドは、現在のペイロードの末尾を見つけるために使用される。「Bit Field 2」から始まる他のMPFヘッダは、現在のペイロードの末尾の後に続きうる。「Offset Present」ビットが0の場合、「Offset」フィールドは存在せず、MPFがRTPとともに使用される場合、現在のペイロードはトランスポートパケットの末尾まで、またはRTPヘッダ内の「Padding」ビットが1の場合にRTPパディング領域の始めまで伸びる。
「Sync Point」ビット(S):このビットは、MAUが同期点MAUの場合に1に設定される。「Discontinuity」ビット(D1):このビットは1に設定され、トランスポートパケットのシーケンス番号(例えば、RTPが使用されている場合に、RTPシーケンス番号)が「ギャップ」を示していないとしても、1つまたは複数のMAUが欠落していることを示す。「Droppable」ビット(D2):このビットが1であり、いくつかのMAUを落とす必要がある場合、このMAUは、D2ビットが0に設定されているMAUほどマイナスの影響を及ぼすことなく落とすことができる。「Encryption」ビット(E):このビットは1に設定され、ペイロードが暗号化されたデータを含むことを示す。このビットは、ペイロードが暗号化されたデータを含まない場合に0に設定されなければならない。「Bit Field 3 Present」(B3P)ビット:このビットが1の場合、1バイトの「Bit Field 3」フィールドが、「Length」フィールドの後に挿入される。「Offset」:「Offset」フィールドの後に続く最初のバイトから数えた、現在のペイロードの終わりまで、バイト数でオフセットを指定する16ビットフィールド。言い換えると、「Offset」フィールドの値は、もしあれば「MAU Timing」セクションのサイズに、現在のペイロードのサイズを加えた値である。
「Bit Field 2」の「B3P」ビットの値は、「Bit Field 3」が存在するかどうかを判定する。「Bit Field 3」のすべてのビットに対するデフォルト値は、0である。図12は、MPFのビットフィールド3の例示的なレイアウトを示す。「Decode Time Present」ビット(D3):このビットが1の場合、32ビット「Decode Time」フィールドが、「Bit Field 3」の後から、「Presentation Time」フィールドの前までの間に挿入される。「Presentation Time Present」ビット(P):このビットが1の場合、32ビット「Presentation Time」フィールドが、「Decode Time」の後から、「NPT」フィールドの前までの間に挿入される。「NPT Present」ビット(N):このビットが1の場合、64ビットの「NPT」フィールドが、「Presentation Time」フィールドの直後に挿入される。R6、R7、R8、R9:1に設定されているこれらのビットのそれぞれについて、受信機側では、32ビットフィールドが「NPT」フィールドと「Extension」との間に追加されていると想定する。これらの32ビットフィールドの意味は、本明細書では定義されていない。32ビットフィールドの意味を認識しない受信機は、それらを無視する。
「Extension Present」ビット(X):このビットが1の場合、可変サイズ「Extension」フィールドが、「NPT」フィールドの後に挿入される。「Decode Time」:32ビットフィールド。このフィールドで、MAUの復号化時間を指定する。RTPが使用される場合、このフィールドで、RTPヘッダ内の「Timestamp」フィールドに使用されるのと同じ時間単位を使用して、MAUの復号化時間を指定する。「Presentation Time」:32ビットフィールド。このフィールドで、MAUのプレゼンテーション時間を指定する。「NPT」フィールド:64ビットタイムスタンプ。「NPT」フィールドでは、MAUが属する通常再生時間時系列内の位置を指定する。
図13は、一実施形態による、MPFヘッダの拡張フィールドの例示的レイアウトを示している。「Extension」フィールドは、フィールドの1つまたは複数の集まりを含む。図13は、そのような1つの集まりに含まれるフィールドのレイアウトを例示している。「L」ビット:このビットが1の場合、これは、「Extension」ビットの最後の集まりである。このビットが0の場合、「Extension Data」フィールドの末尾の後に、「Extension」フィールドの少なくとももう1つの集まりが続く。
「Extension Type」:「Extension Data」フィールドの内容を識別するために使用される7ビットフィールド。それに加えて、値0と127は、将来使用するために予約されている。「Extension Length」:このフィールドの直後に出現する「Extension Data」フィールドのバイト数によるサイズを示す8ビットの数値。「Extension Data」:可変長フィールド。このフィールドのサイズは、「Extension Length」フィールドにより与えられる。
「Extension」フィールド内のフィールドは、初期化ベクトル拡張が使用される場合に以下の値を有する。
● 「Extension Type」:2である。
● 「Extension Length」:バイト数による「Extension Data」フィールドのサイズ。
● 「Extension Data」:現在のMAUに対する初期化ベクトルの一部として使用される、1つまたは複数のバイトのシーケンス。この拡張が存在する場合、暗号化ユニットは、完全なMAUである。MAUが複数のペイロードに断片化される場合、初期化ベクトル拡張は、第1のペイロード内にのみ存在する。
「Extension」フィールド内のフィールドは、キーID拡張が使用される場合に以下の値を有する。
● 「Extension Type」:3である。
● 「Extension Length」:バイト数による「Extension Data」フィールドのサイズ。
● 「Extension Data」:現在のペイロードを復号化するために使用する復号化キーを識別する、1つまたは複数のバイトのシーケンス。
キーID拡張は、異なるキーID拡張により置き換えられるまで有効である。したがって、この拡張は、前のペイロードの復号化キーと異なる復号化キーの使用をペイロードが必要とする場合にのみ使用される。しかし、前のペイロードが失われたトランスポートパケット内に含まれていた場合、受信機は、復号化キーの変更が必要であることを認識しない場合がある。ペイロードが誤ったキーで復号化され、この状況が検出されない場合、望ましくないレンダリングアーチファクトが生じる可能性がある。
このような問題の重大さを軽減するアプローチの1つは、同期点であるすべてのMAUの第1のペイロードに対しキーID拡張を指定することである。これは、MAUが失われることで、受信機が次の同期点MAUを受け取るまですべてのMAUを強制的に破棄することが知られている場合にはよい解決策である。より控え目な解決策は、それぞれの複数ペイロードトランスポートにおける第1のペイロードに対しキーID拡張を指定することである。この解決策は、パケット喪失に対しロバストであるが、それは、相互依存ペイロードが、すべて、単一のトランスポートパケット内に含まれるからである。
MPEGビデオヘッダが存在する場合、それらは、後続フレームの前に来る。特に、
● MPEG Video_Sequence_Headerは、存在する場合、MAUの先頭にある。
● MPEG GOP_headerは、存在する場合、MAUの先頭にあるか、またはVideo_Sequence_Headerの後に続く。
● MPEG Picture_Headerは、存在する場合、MAUの先頭にあるか、またはGOP_headerの後に続く。
RFC 2250とは異なり、ビデオを含むMAUが断片化された場合、スライス境界で断片化を実行する必要はない。
MAUは、さまざまな理由から複数のトランスポートパケットにまたがって断片化される可能性がある。例えば、MAUは、トランスポートパケットサイズの制限が存在し、MAUの特定の部分に対する暗号化パラメータに違いがある場合に断片化される可能性がある。RTPヘッダフィールドが解釈される場合、RTPヘッダ内の「Timestamp」フィールドは、90kHzの精度でサンプルのPTSに設定され、「Payload Type(PT)」フィールドは、帯域外ネゴシエーション機構に従って(例えば、SDPを使用して)設定される。MPF、パケット指定情報セクションに関して、「Send Time」フィールドの存在はオプションであり、「Correspondence」フィールドの存在はオプションであり、「Bit Field 2 Present」ビット(B2P)は、ペイロードが、暗号化されたMAUの一部、または暗号化されたMAUのフラグメントを含む場合に設定される。
上記に照らして、MPFにより、異なる暗号化パラメータに従って単一のMAUを暗号化することができる。これは、暗号化された単一のMAUのフラグメントを備え、他を平文中に残す機能を備える。このような場合、MAUは、複数のペイロードに断片化することができ、それぞれ異なる暗号化パラメータを有する。例えば、暗号化されたMAUまたはMAUのフラグメントは、以下の基準に従って値およびフィールドを設定される。
● Packet Infoセクション内の「Bit Field 2 Present」ビット(B2P)は、1に設定され、「Bit Field 2」が存在することを示す。
● MAU Propertiesセクション内の「Encryption」ビット(E)は、1に設定され、ペイロードが暗号化されることを示す。
● 「MAU Timing」セクション内の「Extension Present」ビット(X)は、1に設定され、拡張フィールドが存在することを示す。
● 「Initialization Vector」拡張が含まれる。以下の値が設定される。
○ 「Extension Type」は2に設定される。
○ 「Extension Length」は、「Extension Data」フィールドがデータセグメントIDのみを含む場合に8(64ビットを意味する)に、「Extension Data」フィールドがデータセグメントIDとブロックIDの両方を含む場合に16 (128ビットを意味する)に設定される。
○ 「Extension Data」は、初期ブロックIDが0の場合に上述のようなデータセグメントID値で設定される。初期ブロックIDが0と異なる場合に、「Extension Data」は、初期ブロックIDが後に続くデータセグメントIDに設定される。
○ この拡張は、MAUのそれぞれの暗号化されたペイロードに関して含まれる。
● 「Key ID」拡張が含まれる。以下の値が設定される。
○ 「Extension Type」は3に設定される。
○ 「Extension Length」は16(128ビットを意味する)に設定される。
○ 「Extension Data」は、このMAUに対応するライセンスから得たキーID値で設定される。
● 「Initialization Vector」および「Key ID」拡張は、複数のMAUを含むそれぞれの複数ペイロードトランスポートパケット内の新しいMAUの第1のペイロードについて含まれる。これにより、受信機は、いくつかのトランスポートパケットが失われた場合でも、現在のキーIDについて認識することが保証される。
MAU Propertiesセクションは、以下のように解釈される。
● 「Sync Point」ビット(S)は、MAUがビデオI−フレームまたはオーディオフレームを含む場合にセットされる。
● 「Discontinuity」ビット(Dl)は、1つまたは複数のMAUが欠損している場合にセットされる。例えば、ビデオフレームが、フレームドロップトランスレータにより落とされた場合。
● 「Droppable」ビット(D2)の利用はオプションである。それが使用されるべき場合の定義は、本明細書の範囲を外れている。
● 「Encryption」ビット(E)は、ペイロードが、暗号化されたMAUの一部、または暗号されたMAUのフラグメントを含む場合にセットされる。
MAU Timingセクションは、以下のように解釈される。
● 「Decode Time」フィールドは、オプションである。使用される場合、MAUのDTSを含む。
● 「Presentation Time」フィールドは、オプションである。
● 「NPT」フィールドは、オプションである。
○ 「Extension Present」ビット(X)は、1つまたは複数の拡張ヘッダが存在する場合にセットされる。
例示的な手順
図14は、一実施形態により、ESコンテンツを保護する例示的な手順1400を示している。例示することを目的として、図1のES保護モジュール112、マッピングモジュール114、図2のトランスポートストリームスクランブルモジュール210、および/または逆多重化およびパッケージ化モジュール212のうちの1つまたは複数により手順1400のオペレーションが実行される。アクションの順序の変更および修正を含む、さまざまな変更および修正は、当業者にとっては、本明細書の説明から明らかであろう。
図14を参照すると、ブロック1405において、エレメンタリストリーム(ES)は、コンピューティングデバイス102またはコンテンツソース202により受信されるか、または他の何らかの方法でアクセスされる。アクセスされたESは、トランスポートストリームと無関係であるか、またはトランスポートストリームにより配送することができる。ブロック1410における手順1400で、ESのMAU部分を保護する。一実装では、これらの保護オペレーションは、共通スクランブルとは無関係に実行される。他の実装では、これらの保護オペレーションは、例えば、トランスポートストリームを共通スクランブルした場合に、共通スクランブルを使用して実行される。ブロック1415において、トランスポートストリームがブロック1405でアクセスされた場合、元の暗号化が保持されるようにトランスポートストリームがESに逆多重化される。モジュール212の逆多重化オペレーションは、トランスポートストリーム逆多重化オペレーションを実行する例示的なコンポーネントを示している。
ブロック1420における手順1400で、保護されているESがMAUペイロードフォーマット(MPF)にマッピングされる。それぞれのMAUをMPFにマッピングすることで、メディアコンシューマが他のESと無関係にそれぞれのESを処理し、他のMAUとは無関係にそれぞれのMAUを処理するのに十分な情報が、マッピングされたESをカプセル化するトランスポートパケットを受け取るメディアコンシューマに与えられる。ブロック1430における手順1400で、MPFにマッピングされたESがトランスポートプロトコルにカプセル化される。一実装では、トランスポートプロトコルは、リアルタイム転送プロトコル(RTP)である。ブロック1440における手順1400で、トランスポートプロトコルに基づくトランスポートパケットをメディアコンシューマに伝達し、処理する。復号化を含む、このような処理により、メディアコンシューマは、トランスポートパケットに含まれるペイロードデータを受け取ることができる。
結論
ESコンテンツを保護することは構造的特徴および/または方法論的なオペレーションまたはアクションに固有の言語で説明されているが、付属の請求項で定められている実装は、説明された特定の特徴またはアクションに必ずしも限られないことは理解されるであろう。むしろ、特定の特徴およびオペレーションは請求されている主題を実施するための複数の実施形態の例として開示されている。
一実施形態による、ESコンテンツを保護する例示的なコンピューティングシステムを示す図である。 一実施形態による、トランスポートストリームにより配送されるESコンテンツを保護する例示的な実施形態を実装することができる例示的なネットワーク接続環境を示す図である。 カウンタモードで高度暗号化標準を使用してESメディアコンテンツを暗号化するオペレーションの例示的な態様を示す図である。 一実施形態による、保護されたESコンテンツとともにトランスポートストリーム内に挿入する例示的な暗号方式(TAG)パケットを示す図である。 一実施形態による、送信機側でトランスポートストリーム内のESを保護する例示的な手順を示す図である。 一実施形態による、例示的な共通スクランブルされたトランスポートストリームを示す図である。 一実施形態による、メディアアクセスユニット(MAU)ペイロードフォーマット(MPF)ヘッダの例示的な高水準構造を例示する図である。 一実施形態による、図7のMPFヘッダの例示的な詳細を示す図である。 一実施形態による、MPFを使用する3つのリアルタイムトランスポートパケット(RTP)パケットの例示的なシーケンスを示す図である。 一実施形態による、単一のメディアアクセスユニット(MAU)が同じRTPパケット内の3つのフラグメントに分割されている一実施例を示す図である。 標準的な12バイトRTPヘッダを例示する図である。 MPFのビットフィールド3の例示的なレイアウトを示す図である。 一実施形態による、MPFヘッダの拡張フィールドの例示的なレイアウトを示す図である。 一実施形態による、ESコンテンツを保護する例示的な手順を示す図である。

Claims (20)

  1. コンピュータに実装される方法であって、
    エレメンタリストリームコンテンツのメディアアクセスユニット(MAU)を識別するステップと、
    単一のビデオまたはオーディオフレームを表す1つまたは複数のデータセグメントを含む前記複数のMAUのうちのそれぞれのMAU毎に、
    前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記1つまたは複数のデータセグメントに基づいて暗号境界を選択するステップと、
    前記MAUを保護するステップを含み、保護するステップは、
    前記暗号境界に基づいて前記MAUの一部を暗号化するステップと、
    前記MAUを、MAUペイロードフォーマットにマッピングするステップとを含み、
    前記MAUペイロードフォーマットは、前記エレメンタリストリームの異なるどの1つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのMAUとも無関係に前記MAUの処理を規定する方法。
  2. 前記エレメンタリストリームコンテンツは、トランスポートストリームにより配送され、保護するステップは、さらに、前記複数のMAUのうちの1つのMAUを構成するデータセグメントのそれぞれが、完全に暗号化されているか、またはまったく暗号化されていないかのいずれかであるように前記トランスポートストリームを共通スクランブルするステップを含む請求項1に記載の方法。
  3. 保護するステップは、さらに、カウンタモードの高度暗号化標準により前記1つまたは複数のデータセグメントのうちの別々のセグメントを暗号化するステップを含む請求項1に記載の方法。
  4. 前記MAUの一部は、平文中に残される請求項1に記載の方法。
  5. 前記MAUをマッピングするステップは、さらに、複数のトランスポートプロトコルペイロードにまたがって前記MAUを断片化するステップを含む請求項1に記載の方法。
  6. 前記MAUをマッピングするステップは、さらに、単一トランスポートプロトコルパケット内の前記MAUについて複数のペイロードを関連付けるステップを含む請求項1に記載の方法。
  7. さらに、
    単一のトランスポートプロトコルパケット内の前記MAUに対する複数のペイロードを関連付けるステップを含み、
    前記複数のペイロードのうちの2つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項1に記載の方法。
  8. 前記MAUペイロードフォーマットは、トランスポートプロトコルパケット内のすべてのMAUに関連付けられているパケット固有の情報を含む請求項1に記載の方法。
  9. 前記MAUペイロードフォーマットは、
    特定のMAUを記述するためのMAU propertiesセクションと、
    前記MAUが断片化された場合に、前記MAUの断片化された部分が失われたときに受信機側で前記MAUを解析するのに使用できる情報を含む前記プロパティセクションとを含む請求項1に記載の方法。
  10. 前記MAUペイロードフォーマットは、前記MAUに関連付けられているタイムスタンプに関する情報を提供するMAU timingセクションを含む請求項1に記載の方法。
  11. 前記情報は、受信機により、プレゼンテーション内でシークする位置指定を補助するための、前記MAUに関連付けられている通常再生時間(NPT)時系列を含む請求項10に記載の方法。
  12. 前記情報は、前記MAUのコンテンツを前記受信機が提示する時期を指示するプレゼンテーション時間を含む請求項10に記載の方法。
  13. 前記プレゼンテーション時間は、トリックプレイが使用されることを意識せずに復号器が前記MAUを復号化できるリアルタイム速度でインクリメントする請求項12に記載の方法。
  14. 保護するステップは、さらに、
    トランスポートストリームを分析して、暗号化されずに通る前記トランスポートストリームの部分を決定するステップを含み、
    保護するステップは、さらに、前記トランスポートストリームの共通スクランブルされた部分をバイパスする処理を行うように前記トランスポートストリームを準備するステップを含む請求項1に記載の方法。
  15. コンピュータに実装される方法であって、
    エレメンタリストリームを受信し、それぞれのエレメンタリストリーム(ES)は複数のメディアアクセスユニット(MAU)で表され、それぞれのMAUは前記ESのビデオまたはオーディオの単一フレームに対応し、それぞれのエレメンタリストリームはMAUペイロードフォーマット(MPF)をカプセル化するトランスポートプロトコルにマッピングされるステップと、
    前記トランスポートストリームを処理し、前記MPFによりそれぞれのESは他のどのESとも無関係に処理することができ、それぞれのMAUを他のどのMAUとも無関係に処理することができるステップとを含む方法。
  16. 前記トランスポートプロトコルは、リアルタイム転送プロトコル(RTP)である請求項15に記載の方法。
  17. 前記複数のMAUのうちの1つのMAUの一部は、平文中に残される請求項15に記載の方法。
  18. 前記複数のMAUのうちの1つのMAUが、複数のトランスポートプロトコルペイロードにまたがって断片化されるか、または前記MAUに対する複数のペイロードが、単一のトランスポートプロトコルパケット内にある請求項15に記載の方法。
  19. 前記複数のペイロードのうちの2つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項18に記載の方法。
  20. コンピューティングデバイスであって、
    エレメンタリストリームコンテンツのメディアアクセスユニット(MAU)を識別する識別手段と、
    単一のビデオまたはオーディオフレームを表す1つまたは複数のデータセグメントを含む前記複数のMAUのうちのそれぞれのMAU毎に、
    前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記1つまたは複数のデータセグメントに基づいて暗号境界を選択する選択手段と、
    前記MAUを保護する保護手段とを含み、保護手段は、
    前記暗号境界に基づいて前記MAUの一部を暗号化する暗号化手段と、
    前記MAUを、MAUペイロードフォーマットにマッピングするマッピング手段とを含み、
    前記MAUペイロードフォーマットは、前記エレメンタリストリームの異なるどの1つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのMAUとも無関係に前記MAUの処理を規定するコンピューティングデバイス。
JP2008526267A 2005-08-12 2006-08-10 エレメンタリストリームコンテンツの保護 Withdrawn JP2009505516A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
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
JP2009505516A true JP2009505516A (ja) 2009-02-05

Family

ID=37758250

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008526267A Withdrawn JP2009505516A (ja) 2005-08-12 2006-08-10 エレメンタリストリームコンテンツの保護

Country Status (7)

Country Link
US (1) US20060184790A1 (ja)
EP (1) EP1913776A4 (ja)
JP (1) JP2009505516A (ja)
KR (1) KR20080033983A (ja)
CN (1) CN101243687A (ja)
BR (1) BRPI0614675A2 (ja)
WO (1) WO2007022038A2 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017130966A (ja) * 2011-06-14 2017-07-27 サムスン エレクトロニクス カンパニー リミテッド マルチメディアシステムにおけるメディアコンテンツ復号方法
JP2018093497A (ja) * 2013-09-20 2018-06-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置
JP2018182768A (ja) * 2011-01-19 2018-11-15 サムスン エレクトロニクス カンパニー リミテッド 放送システムにおけるマルチメディアデータの転送装置及び方法
US20210153156A1 (en) * 2014-03-24 2021-05-20 Imagination Technologies Limited High definition timing synchronisation function
JP2022003834A (ja) * 2013-09-20 2022-01-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置

Families Citing this family (42)

* Cited by examiner, † Cited by third party
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
KR101920439B1 (ko) * 2011-04-28 2019-02-14 삼성전자주식회사 공용 인터페이스를 통해 수신 제한 모듈로 암호화된 데이터를 전송하기 위한 데이터 전송 장치 및 그에 적용되는 방법, 수신 제한 모듈 그리고 시스템.
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
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)

* Cited by examiner, † Cited by third party
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 日本電気株式会社 トランスポートストリームの暗号化装置及び編集装置並びにこれらの方法

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10484445B2 (en) 2011-01-19 2019-11-19 Samsung Electronics Co., Ltd. Apparatus and method for transmitting multimedia data in a broadcast system
US10911510B2 (en) 2011-01-19 2021-02-02 Samsung Electronics Co., Ltd. Apparatus and method for transmitting multimedia data in a broadcast system
JP2018182769A (ja) * 2011-01-19 2018-11-15 サムスン エレクトロニクス カンパニー リミテッド 放送システムにおけるマルチメディアデータの転送装置及び方法
US10506007B2 (en) 2011-01-19 2019-12-10 Samsung Electronics Co., Ltd. Apparatus and method for transmitting multimedia data in a broadcast system
JP2018182768A (ja) * 2011-01-19 2018-11-15 サムスン エレクトロニクス カンパニー リミテッド 放送システムにおけるマルチメディアデータの転送装置及び方法
US10110655B2 (en) 2011-06-14 2018-10-23 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving media contents in multimedia system
JP2019165456A (ja) * 2011-06-14 2019-09-26 サムスン エレクトロニクス カンパニー リミテッド マルチメディアシステムにおけるメディアパケット送信方法
US10447754B2 (en) 2011-06-14 2019-10-15 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving media contents in multimedia system
US10542065B2 (en) 2011-06-14 2020-01-21 Samsung Electronics Co., Ltd. Method and apparatus for transmitting/receiving media contents in multimedia system
JP2017130966A (ja) * 2011-06-14 2017-07-27 サムスン エレクトロニクス カンパニー リミテッド マルチメディアシステムにおけるメディアコンテンツ復号方法
JP2017153127A (ja) * 2011-06-14 2017-08-31 サムスン エレクトロニクス カンパニー リミテッド メディアコンテンツ復号装置
US12010395B2 (en) 2013-09-20 2024-06-11 Panasonic Intellectual Property Corporation Of America Transmission method, reception method, transmitting apparatus, and receiving apparatus
US10499113B2 (en) 2013-09-20 2019-12-03 Panasonic Intellectual Property Corporation Of America Transmission method, reception method, transmitting apparatus, and receiving apparatus
JP2021007258A (ja) * 2013-09-20 2021-01-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置
JP2022003834A (ja) * 2013-09-20 2022-01-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置
JP7238066B2 (ja) 2013-09-20 2023-03-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法、受信方法、送信装置及び受信装置
JP2018093497A (ja) * 2013-09-20 2018-06-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置
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
EP1913776A4 (en) 2014-08-20
WO2007022038A2 (en) 2007-02-22
KR20080033983A (ko) 2008-04-17
EP1913776A2 (en) 2008-04-23
BRPI0614675A2 (pt) 2011-04-12

Similar Documents

Publication Publication Date Title
JP2009505516A (ja) エレメンタリストリームコンテンツの保護
US20060036551A1 (en) Protecting elementary stream content
US7636439B2 (en) Encryption method, encryption apparatus, data storage distribution apparatus and data delivery system
US7356147B2 (en) Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient
US8135949B2 (en) Digital content distribution
US8949592B2 (en) System and methods for providing live streaming content using digital rights management-based key management
JP4188958B2 (ja) 暗号化方法及びデータ配信システム及び暗号化装置及びデータ蓄積配信装置
US7447313B2 (en) Pointers to encrypted data in RTP header
US8548164B2 (en) Method and device for the encryption and decryption of data
US20100195827A1 (en) Method and apparatus for encrypting transport stream of multimedia content, and method and apparatus for decrypting transport stream of multimedia content
US7746853B2 (en) Method and apparatus for transporting broadcast video over a packet network including providing conditional access
JP2005287039A (ja) 共通スクランブル処理
KR20190095072A (ko) 저 지연 방송 스크램블링 방법 및 시스템
AU2004224936A1 (en) Encryption of MPEG Bitstreams

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20091110