データストリームを処理する装置及び方法
データストリーム１８００を処理する装置２３００であって、該装置２３００は、隣接するフレーム１９０２の間に解読されたフレーム境界部分１９０１を有するような少なくとも部分的に解読されたデータストリーム１９００の隣接するフレーム１９０２をフレーム境界部分１９０１で分割する分割ユニット２３０５と、分割されたフレーム１９０２を所定の複製レートに従って複数回複製する複製ユニット２３０６と、複製された分割されたフレーム１９０２を接続する接続ユニット２３０７とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データストリームを処理する装置に関する。
【０００２】
また、本発明はデータストリームを処理する方法にも関する。
【０００３】
また、本発明はプログラムエレメントにも関する。
【０００４】
また、本発明はコンピュータ読み取り可能な媒体にも関する。
【背景技術】
【０００５】
電子娯楽（エンターテインメント）装置は、益々重要になってきている。特に、益々多くのユーザがハードディスク型オーディオ／ビデオプレーヤ及び他の娯楽装置を購入している。
【０００６】
記憶空間の低減はオーディオ／ビデオプレーヤの分野においては重要な問題であるので、オーディオ及びビデオデータは、しばしば、圧縮された態様で、及び保全的理由で暗号化された態様で記憶される。
【０００７】
ＭＰＥＧ２は、動画及び関連するオーディオの汎用的符号化のための規格であり、フレームデータからＧＯＰ（"グループ・オブ・ピクチャ"）構造と呼ばれる特定の順序で配列され得るビデオストリームを生成する。ＭＰＥＧ２ビデオのビットストリームは、画像を符号化する一連のデータフレームからなっている。画像を符号化する３つの方法は、イントラ符号化（Ｉ画像）、順方向予測（Ｐ画像）及び双方向予測（Ｂ画像）である。イントラ符号化されたフレーム（Ｉフレーム）は作りツリーに復号可能なフレームである。順方向予測フレーム（Ｐフレームは）、先行するＩフレーム又はＰフレームの情報を必要とする。双方向予測フレーム（Ｂフレーム）は先行する及び／又は後続のＩフレーム又はＰフレームの情報に依存する。
【０００８】
メディア再生装置においては、メディアコンテンツが通常速度で再生される通常再生モードから、メディアコンテンツが例えば低減された速度（"スロー順方向"）で、静止画像で又はその逆等の変更された態様で再生されるようなトリックプレイ再生モードへ切り換えることが興味ある機能である。
【０００９】
米国特許出願公開第２００５／０１５７７１４Ａ１号は、パケット型のスクランブルされたストリームを処理する方法であって、パケットストリームにおける複数のスクランブルされたパケットを受信するステップと、該スクランブルされたパケットの何れかをスクランブル解除するステップと、該スクランブル解除されたパケットの少なくとも１つと上記スクランブルされたパケットの少なくとも１つを含むような変更されたパケットストリームを送信するステップとを含むような方法を開示している。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、データストリームの効率的な処理を可能にすることにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、独立請求項によるデータストリームを処理する装置、データストリームを処理する方法、プログラムエレメント及びコンピュータ読み取り可能な媒体が提供される。
【００１２】
本発明の一実施例によれば、データストリームを処理する装置であって、隣接するフレーム間に解読されたフレーム境界部分を有するような部分的に解読された（及び部分的に暗号化された）データストリームの隣接するフレームを斯かるフレーム境界部分において分割する分割ユニットと、分割されたフレームを所定の複製レート（例えば、"３"等のトリックプレイ係数）に従って複数回複製する複製ユニットと、斯かる複製された分割されたフレームを接続する接続ユニットとを有するような装置が提供される。
【００１３】
本発明の他の実施例によれば、データストリームを処理する方法であって、隣接するフレーム間に解読されたフレーム境界部分を有するような部分的に解読された（及び部分的に暗号化された）データストリームの隣接するフレームを斯かるフレーム境界部分において分割するステップと、分割されたフレームを所定の複製レートに従って複数回複製するステップと、斯かる複製された分割されたフレームを接続するステップとを有するような方法が提供される。
【００１４】
更に、本発明の他の実施例によれば、コンピュータ読み取り可能な媒体であって、プロセッサにより実行された場合に上述した方法を制御又は実行するようなコンピュータプログラムが記憶された媒体が提供される。
【００１５】
更に、本発明の更に他の実施例によれば、プロセッサにより実行された場合に上述した方法を制御又は実行するようなプログラムエレメントが提供される。
【００１６】
本発明の実施例によるデータ処理は、コンピュータプログラムにより、即ちソフトウェアにより、又は１以上の特別な電子最適化回路を使用することにより、即ちハードウェアで、又は複合形態で、即ちソフトウェア構成要素及びハードウェア構成要素により実現することができる。
【００１７】
本発明の実施例による構成は、部分的に解読され且つ部分的に暗号化されたデータストリームを、異なるフレームが境界部分で分割され、後に斯かる分割されたフレームをスロー順送り又はスロー逆送り又は静止、より一般的にはスローモーション、トリックプレイ再生を可能にするような態様で再び接続することができるような形で処理することができるという利点を提供する。従って、隣接するフレーム間の平文部分は、どの位置で異なるフレームを切断すべきか、スローモーションのフィーチャを提供するために種々のフレームを複数回繰り返すべきか、及び適切な音声及び／又は画像が得られるように複製されたフレームシーケンスを一緒にすべきかの指示子として働くことができる。
【００１８】
一実施例によれば、フレーム分割アルゴリズム及び（分割及び複製された）フレームの接着が可能にされる。一実施例によるアルゴリズムによると、部分的に暗号化された"複合"スロー順送りＤＶＢ（"デジタルビデオ放送"）ストリームを、完全に暗号化された通常プレイ（例えば、ＭＰＥＧ）ストリームから発生することができる。このような手順は、トランスポートストリームのうちの画像フレーム境界を含む暗号化パケットのみを、スロー順送りを容易化するための対応する平文パケットにより選択的に置換するステップを含むことができる。更に、パケットを画像フレーム境界において分割することができ、スロー順送りストリームを、フレームを複製することにより発生することができる。画像フレーム境界におけるパケットは、必要ならば詰め込むことができる。次いで、画像開始コードが２つのパケットに跨る位置を識別することができ、これらに対して対応する補正を適用することができるが、該処理は接着と称することができる。
【００１９】
一実施例によれば、ＭＰＥＧ準拠デコーダに対するデジタルインターフェースを備えるようなＭＰＥＧトランスポートストリームを記憶するための記憶装置が設けられ、該デコーダは、暗号化されたＤＶＢストリームのスロー順送りプレイモードのためのＭＰＥＧ準拠ストリームを提供することができる。特別な筋書きにおいては、平文のスロー順送りストリームを解読及び生成する単純な処理は適切ではない可能性がある。何故なら、全情報が平文になるかもしれないからである。これは、保全の観点から望ましくないであろう。更に、家電装置におけるＤＶＢ暗号器の使用は許可されないであろう。この結果、処理は暗号化されたＤＶＢトランスポートストリームに対して実行されねばならないことになる。
【００２０】
かくして、本発明の一実施例によれば、複合（ハイブリッド）トランスポートストリームを使用することができ、該複合トランスポートストリームは、情報の主要部は暗号化されたままであることを保証しながら、スロー順送りＭＰＥＧ準拠トランスポートストリームの生成を可能にするために要する少量の（特には、最少量の）平文情報を有する。このような状況における１つの態様は、上記の暗号化されたトランスポートストリームにおける個々のフレームが、スロー順送りモードを提供するために繰り返されるというものである。この結果、特別なケースで、パケット境界を横切るＭＰＥＧ画像開始コードを補正するために前記フレームの分割及び後の個々のフレームの接着処理が要となる。この出願では、上記接着を実現する可能性が開示される。
【００２１】
かくして、本発明の実施例は、フレームを分離するためにパケットを分割するステップを含む。これは、Ｂフレームを繰り返すためにフレームを複製するステップ、及び元のＩ又はＰフレームを繰り返すために空のフレームを使用するオプションを含む。
【００２２】
更に、部分的に暗号化された開始コードで開始し、該暗号化された（暗号化されていない）パケットに存在する開始コードバイトの量を決定するアルゴリズムを実施することも可能である。結果として、パケットの接着が可能となる。パケットの連結の結果として、所定の閾値（例えば、４バイト）より大きな開始コードとなった場合、上記アルゴリズムは削除されるべきバイトの量を計算することができる。パケットの連結の結果として、所定の閾値（例えば、４バイト）より小さな開始コードとなった場合、追加の接着パケットを挿入することができる。
【００２３】
従って、本発明の一実施例は、パケットの分割及び接着につながるような、ストリームを暗号化するための画像開始コードの検出を目指す。
【００２４】
接着は、当該データストリームにおける上記開始コードの一部が存在する位置において実行することができ、追加のパケットを挿入するステップを含むことができる。詰め込みのために、特にはトランスポートストリームレベルの詰め込みのためにアダプテーションフィールド（ＡＦ）を挿入することができる。他の例として、例えば当該ストリームに１以上の単なる"ゼロ"を挿入することを含み、基本ストリームレベルの詰め込みも可能である。
【００２５】
当該データストリームのうちのデータストリーム処理を可能にするために解読される部分は、１％又はそれ以下の程度とすることができ、従って当該ストリームの９９％又はそれ以上は暗号化されたままとすることができる。
【００２６】
次に、本発明の他の実施例を説明する。
【００２７】
以下においては、データストリームを処理する装置の実施例を説明する。しかしながら、これら実施例は、データストリームを処理する方法、コンピュータ読み取り可能な媒体及びプログラムエレメントにも適用することができる。
【００２８】
当該装置は、（全体的に又は部分的に）暗号化されたデータストリームにおける隣接するフレーム間の暗号化されたフレーム境界部分を、解読されたフレーム境界部分により選択的に置換して部分的に解読されたデータストリームを形成する解読ユニットを有することができる。言い換えると、完全に暗号化されたデータストリームは、隣り合うフレーム間の暗号化された部分が対応する解読された部分により置換されるように処理されることが可能である。当該解読ユニットは、暗号化されたコンテンツを記憶する記憶装置（例えば、ハードディスク又はフラッシュメモリ）から分離して配置することができるか、又は斯様な記憶装置に統合することができる。また、斯様な記憶装置が既に部分的に解読された及び部分的に暗号化されたデータストリーム（これも、複合ストリームと称することができる）を記憶していることも可能である。
【００２９】
特には、上記解読ユニットは、暗号化されたデータストリームにおける隣接するフレーム間の暗号化されたフレーム境界部分のみを、解読されたフレーム境界部分により選択的に置換すると共に、全ての他のフレーム部分は暗号化されたままに維持するように構成することができる。従って、暗号化されたデータストリームのうちの必要な部分のみが解読され、これによりトリックプレイストリームの発生が、これらの平文部分に基づいて可能とされる。しかしながら、当該ストリームの部分（多くの場合には、主又は主要部分）が暗号化されたままとなり、かくして、高レベルの保全が達成される。
【００３０】
上記解読ユニットは、暗号化されたフレーム境界部分を解読されたフレーム境界部分により選択的に置換して、部分的に解読されたデータストリームを、小さな、好ましくは最少の量の解読された部分でトリックプレイストリームを発生するための基礎として形成するように構成することができる。この実施例によれば、略完全に暗号化されたデータストリームを、特にはスロー順送りストリーム又はスロー逆送りストリームであり得るような、スローモーションストリーム等のトリックプレイストリームを発生するために必要とされる部分のみが選択的に解読されたものと同時的に得ることが可能になる。
【００３１】
前記分割ユニットは、各分割フレームの開始部に平文パケットを挿入するように構成することができ、及び／又は分割パケットの詰め物をするように構成することができる。従って、異なるフレームを分割した後に、平文パケットを斯かる分割されたフレームの各々の終了部及び／又は開始部に挿入することができる。斯様なパケットは、対応するフレームを識別又は特徴付けるのに要する情報を含むことができるか、又は隣接するフレーム間の境界を単に詰めることができる。更に詳細には、分割は実際には挿入ではなく、分割パケットの詰め込み（先ず、前フレームの最終部分、次いで現フレームの最初の部分）である。これは、アダプテーションフィールドにより詰め込むこともできる。
【００３２】
このような平文パケットはヘッダ及び／又はアダプテーションフィールド（Adaptation Field: AF）を有することができる。アダプテーションフィールドなる用語は、ＭＰＥＧ符号化のフィールドから由来するものである。
【００３３】
前記接続ユニットは、複製された分割フレームを、フレーム境界部分（例えば、画像開始コード）が２つのフレームに跨っている場所を識別することに基づいて、及び斯様な識別された場所を訂正することに基づいて接続するように構成することができる。従って、スローモーショントリックプレイに従って複製分割フレームを一緒にする場合の如何なる可能性のある問題も、接着部分を調べることにより除去し又は取り除くことができる。これは、トリックプレイモードにおける再生の品質を改善させる。
【００３４】
前記接続ユニットは、特には、分割されたフレームのフレーム境界部分のサイズを決定すると共に、斯かる分割フレームを該決定されたサイズに基づいて接続するように構成することができる。上記サイズが過度に大きいと判断された場合（例えば４バイトなる閾値を超えた場合）、当該フレーム境界部分又は画像開始コードは対応して短縮され、所定の閾値に従うようにされる。他の場合において、当該フレーム境界部分のサイズが例えば４バイト等の所定の閾値より小さい場合、該サイズは、例えば当該フレーム境界部分に追加の部分を挿入することにより対応して増加される。このような対策を講じることにより、画像開始コードは所望の長さに調整することができ、これはシステム全体の制御性及び操作性を改善し得る。
【００３５】
当該装置は、データストリームを記憶する記憶ユニットを有することができる。このような記憶ユニットはハードディスク又はメモリカードとすることができ、これらは例えばオーディオ及び／又はビデオコンテンツを含むデータストリームを記憶することができる。
【００３６】
当該装置は、完全に暗号化されたデータストリームを処理するように構成することができる。言い換えると、全体のデータストリームは完全に暗号化され、従って許可されないアクセスに対して保全される。この場合、隣接するフレームの間の特別に規定された部分が、対応する平文部分により選択的に置換される。しかしながら、当該処理が実行されるストリームが部分的に又は完全に解読されることも本発明の範囲内である。
【００３７】
当該装置は、イントラ符号化フレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）及び双方向予測フレーム（Ｂフレーム）からなる群の少なくとも１つのフレームを処理するように構成することができる。ＭＰＥＧ２において、Ｉフレームは独立に復号可能なフレームである。Ｐフレームは先行するＩフレーム又はＰフレームの情報を必要とする。Ｂフレームは、先行する及び／又は後続のＩフレーム又はＰフレームの情報に依存する。
【００３８】
当該装置は、ビデオデータ及び／又はオーディオデータのデータストリームを処理するように構成することができる。しかしながら、このようなメディアコンテンツが、本発明の実施例による方式により処理することが可能な唯一のタイプのデータではない。トリックプレイの生成及び同様のアプリケーションは、ビデオ（オーディオビジュアル）データ処理及び（純）オーディオデータ処理の両方にとり課題であり得る。
【００３９】
当該装置は、更に、デジタルデータのデータストリームを処理するように構成することができる。
【００４０】
更に、当該装置は上記の処理されたデータストリームを再生又はプレイする再生ユニットを有することができ、該再生ユニットは前記接続ユニット（の出力端）に接続することができる。このような再生ユニットはスピーカ若しくはイヤホン若しくはヘッドフォン、及び／又はオーディオ及びビジュアルデータの両方を人が知覚できるように再生することができるような光学表示装置を有することができる。
【００４１】
更に、当該装置は前記データストリームをトリックプレイ再生モードで再生するように処理するための発生ユニットを有することができる。トリックプレイ再生モードで再生するためのデータストリームを発生するように構成された斯様なトリックプレイ発生ユニットは、ユーザにより、例えば装置の釦、キーパッド又はリモコン等のユーザインターフェースを介して対応するオプションを選択することにより調整することができる。ユーザにより選択されるトリックプレイ再生モードは、スローモーション再生モード（特には、スロー順送り又はスロー逆送り）、静止（stand still）モード、高速順方向再生モード、高速逆方向再生モード、静止フレーム（freeze frame）再生モード、瞬時リプレイ再生モード及び逆方向再生モードからなる群のうちの１つであり得る。しかしながら、他のトリックプレイストリームも可能である。トリックプレイ係数によるトリックプレイの場合、当該データのうちの一部のみを出力に使用することができるか（例えば、１より大きなトリックプレイ係数）、又は１つの同一のコンテンツを何回か再生することができる（例えば、１より小さなトリックプレイ係数）。
【００４２】
本発明の実施例による装置は、ＭＰＥＧ２データストリームを処理するように構成することができる。ＭＰＥＧ２はＭＰＥＧ（動画専門家グループ）により同意された一群のオーディオ及びビデオ符号化規格の名称であり、ＩＳＯ／ＩＥＣ１３８１８国際規格として公開されている。例えば、ＭＰＥＧ２はオーディオ及びビデオをデジタル衛星及びケーブルＴＶを含む放送信号用に符号化するために使用されるが、ＤＶＤにも使用することができる。
【００４３】
本発明の実施例による装置は、デジタルビデオ記録装置、ネットワーク可能化装置（network-enabled device）、条件付きアクセスシステム（限定受信システム：conditional access system）、携帯オーディオプレーヤ、携帯ビデオプレーヤ、携帯電話、ＤＶＤプレーヤ、ＣＤプレーヤ、ハードディスク型メディアプレーヤ、インターネットラジオ装置、公衆娯楽装置（public entertainment device）及びＭＰ３プレーヤからなる群のうちの１つとして実現することができる。しかしながら、これらのアプリケーションは例示に過ぎない。
【００４４】
本発明の上述した態様及び他の態様は、以下に述べる実施例から明らかであり、これら実施例を参照して説明される。
【発明を実施するための最良の形態】
【００４５】
以下、本発明を実施例に基づき詳細に説明する。
【００４６】
尚、各図は実寸ではなく概念的に示されたもので、異なる図における同一の符号は対応する構成要素を示している。また、当業者にとっては、本発明の他の等価な実施例が本発明の思想から逸脱することなしに可能であること、及び本発明の範囲が請求項によってのみ限定されるものであることは明であろう。
【００４７】
以下、図１ないし図１３を参照して、本発明の実施例によるトランスポートストリームに対する異なる態様のトリックプレイ構成を説明する。
【００４８】
特に、部分的に若しくは全体的に暗号化されているか又は暗号化されていないものとすることが可能なＭＰＥＧ２符号化ストリームに対しトリックプレイを実行するための幾つかの可能性を説明する。以下の説明は、ＭＰＥＧ２トランスポートストリームのフォーマットに固有な方法を目標としている。しかしながら、本発明は該フォーマットに限定されるものではない。
【００４９】
実験は、実際には、所謂タイムスタンプ付きトランスポートストリームという拡張で以って実施された。これは、トランスポートストリームパケットを有し、これらパケットの全てにはトランスポートストリームパケット到達時間が配置された４バイトのヘッダが前に付されている。この時間は、当該パケットの最初のバイトが記録装置で受信された時にプログラムクロック基準（ＰＣＲ）タイムベースの値から導出することができる。これは、ストリームに共にタイミング情報を記憶する好適な方法であり、従って該ストリームの再生は相対的に容易な処理となる。
【００５０】
再生の間における１つの課題は、ＭＰＥＧ２デコーダのバッファが超過する又はアンダフローしないことを保証することである。入力ストリームがデコーダバッファのモデルに準拠していたとしたならば、相対タイミングを復元することは、出力ストリームも準拠することを保証することになる。ここで説明するトリックプレイ方法の幾つかは、タイムスタンプとは独立であり、タイムスタンプを備える又は備えないトランスポートストリームに対して等しく良好に動作する。
【００５１】
図１は、タイムスタンプ付きトランスポートストリームパケット１００を示し、該パケットは１８８バイトの全長１０４を有すると共に、４バイトの長さ１０５を持つタイムスタンプ１０１、パケットヘッダ１０２及び１８４バイトの長さを持つパケットペイロード１０３を含んでいる。下記の説明は、記録されたトランスポートストリームからＭＰＥＧ／ＤＶＢ（デジタルビデオ放送）準拠のトリックプレイストリームを作成する可能性の概要を示すもので、完全に平文の、従ってデータの各ビットを操作することができるものから、完全に暗号化され（例えばＤＶＢ方式により）、従ってトランスポートストリームヘッダ及び幾つかのテーブルのみが操作のためにアクセス可能であり得るストリームまでの全スペクトルの記録ストリームをカバーすることを意図するものである。
【００５２】
ＭＰＥＧ／ＤＶＢトランスポートストリームに対するトリックプレイを作成する場合、コンテンツが少なくとも部分的に暗号化されていると問題が生じ得る。通常の方法であるように基本（エレメンタリ）ストリームレベルまで下降することは可能ではなく、又は解読の前に如何なるパケット化された基本ストリーム（ＰＥＳ）にアクセスすることさえ可能ではない。これは、画像フレームを見つけることが不可能であることをも意味する。既知のトリックプレイエンジンは、この情報をアクセス及び処理することができる必要がある。
【００５３】
この説明の枠内では、"ＥＣＭ"なる用語は権限制御メッセージ（Entitlement Control Message）を指す。このメッセージは、特に、秘密のプロバイダ所有権情報を有し得、とりわけ、ＭＰＥＧストリームを解読するのに要する暗号化された制御ワード（ＣＷ）を含み得る。典型的には、制御ワードは１０〜２０秒内で終了する。ＥＣＭはトランスポートストリーム内のパケットに埋め込まれている。
【００５４】
この説明の枠内において、"キー"なる用語は、特に、スマートカードに記憶することが可能であると共に、トランスポートストリーム内に埋め込まれ得る所謂"権限管理メッセージ（Entitlement Management Message）"即ちＥＭＭを用いて該スマートカードに転送することが可能なデータを指す。これらのキーは、スマートカードによりＥＣＭ内に存在する制御ワードを解読するために使用することができる。斯様なキーの例示的有効期間は１ヶ月である。
【００５５】
この説明の枠内において、"制御ワード（ＣＷ）"なる用語は、特に、実際のコンテンツを解読するために要する解読情報を指す。制御ワードはスマートカードにより解読され、次いで解読コアのメモリに記憶することができる。
【００５６】
ここで、平文ストリームに対するトリックプレイに関する幾つかの態様を説明する。
【００５７】
作成された如何なるＭＰＥＧ２ストリームも、ＭＰＥＧ２準拠のトランスポートストリームであることが好ましい。これは、デコーダを装置内に統合することができるのみならず、例えばIEEE 1394インターフェース等の標準のデジタルインターフェースを介して接続することができるからである。
【００５８】
高圧縮比を達成するためにビデオの時間的冗長性を利用するＭＰＥＧ２等のビデオ符号化技術を使用する場合に発生し得る如何なる問題も考慮されるべきである。フレームは、最早、独立に復号することはできない。複数の画像群（ＧＯＰ）の構造が図２に示されている。図２は、特に、Ｉフレーム２０１及びＰフレーム２０２のシーケンスを伴う幾つかのＭＰＥＧ２のＧＯＰ構造を有するストリーム２００を示している。ＧＯＰのサイズが符号２０３により示されている。該ＧＯＰのサイズ２０３は１２フレームに設定され、ここでは、Ｉフレーム２０１及びＰフレーム２０２のみが示されている。
【００５９】
ＭＰＥＧにおいては、最初のフレームのみが他のフレームとは独立に符号化されているようなＧＯＰ構造を使用することができる。これは、所謂イントラ符号化された、即ちＩフレーム２０１である。予測フレーム即ちＰフレーム２０２は単方向予測により符号化され、図２において矢印２０４により示されるように、これらフレームは前のＩフレーム２０１又はＰフレーム２０２にのみ依存することを意味する。このようなＧＯＰ構造は、典型的には、１２又は１６個のサイズのフレーム２０１、２０２を有する。複数のＧＯＰの他の構造３００が図３に示されている。図３は、特に、Ｉフレーム２０１、Ｐフレーム２０２及びＢフレーム３０１のシーケンスを伴うＭＰＥＧ２のＧＯＰ構造を示す。該ＧＯＰのサイズも、符号２０３で示す。
【００６０】
図３に示すように、双方向予測フレーム即ちＢフレーム３０１も含むＧＯＰ構造を使用することができる。例として、１２フレームのサイズのＧＯＰが選択されている。Ｂフレーム３０１は双方向予測により符号化され、これらフレームが、幾つかのＢフレーム３０１に関して湾曲した矢印２０４により示されているように、前の及び次のＩ又はＰフレーム２０１、２０２に依存することを意味する。圧縮されたフレームの伝送順序は、これらが表示される順序とは同一とは限らない。
【００６１】
Ｂフレーム３０１を復号するためには、当該Ｂフレームの（表示順での）前及び後の両基準フレームが必要とされる。デコーダにおけるバッファの必要条件を最少にするために、圧縮されたフレームは再配列することができる。従って、伝送において、基準フレームは最初にくることができる。送信されたままで再配列されたストリームも、図３の下側に示されている。再配列は、真っ直ぐな矢印３０２により示されている。Ｂフレーム３０１を含むストリームは、全てのＢフレーム３０１がスキップされたなら（跳ばされたなら）良い見え方のトリックプレイ画像となり得る。本例の場合、これは３倍順送りトリックプレイ速度となる。
【００６２】
ＭＰＥＧ２ストリームが暗号化されていなくても（即ち、平文であっても）、トリックプレイは些細なことではない。Ｉフレームのみに基づくスロー逆送りの可能性を短く説明する。ＭＰＥＧ２のＧＯＰの必要な反転のために、効率的なフレームに基づくスロー逆送りは一層困難である。スローモーション順送りとしても知られているスロー順送りは、表示画像が通常速度よりも低い速度で進むようなモードである。スロー順送りの基本的形態は、トリックプレイＧＯＰを発生する高速順送りアルゴリズムを利用する技術を用いて既に可能である。高速順送り速度をゼロと１との間の値に設定する結果として、高速順送りトリックプレイＧＯＰの繰り返しに基づくスロー順送りストリームが得られる。平文ストリームの場合、これは問題とならないが、暗号化されたストリームの場合、これは或る特定の条件ではＩフレームの一部の誤った解読につながり得る。この問題を解決する幾つかのオプションが存在するが、最も適切な方法は、高速順送りトリックプレイＧＯＰを繰り返すのではなく、空のＰフレームの追加により該トリックプレイＧＯＰのサイズを延長することである。この技術は、実際に、スロー逆送りも可能にする。何故なら、高速順送り／逆送りに使用されるトリックプレイＧＯＰに、従って独立に復号可能なＩフレームに基づいているからである。しかしながら、以下のような理由により、この種のＩフレームに基づくスロー順送り又はスロー逆送りを利用することは好ましくない。通常プレイにおけるＩフレーム間の距離は約半秒であり、これは、スロー順送り又は逆送りの場合、スローモーション係数で乗算される。従って、このタイプのスロー順送り／逆送りは、現実にはユーザが馴れているスローモーションではなく、実際には連続する画像の間に大きな時間的距離を伴うスライドショーのようなものである。
【００６３】
静止画モードと呼ばれる他のトリックプレイモードでは、表示画像は停止される。これは、静止画モードの間にわたり当該Ｉフレームに空Ｐフレームを追加することにより達成することができる。これは、最後のＩフレームからの結果の画像が停止されることを意味する。通常プレイから静止画に切り換える場合、これは、ＣＰＩファイル内のデータによる最も近いＩフレームでもあり得る。この技術は、高速順送り／逆送りモードの拡張であり、インターレース除去が使用された場合、良好な静止画像が得られる。しかしながら、通常プレイ又はスロー順送り／逆送りから静止画に切り換える場合、位置的精度が時には十分ではない。
【００６４】
静止画モードはステップモードを実施化するために拡張することができる。ステップコマンドは、当該ストリームを何れかの次の又は前のＩフレームに進める。ステップサイズは、最小で１ＧＯＰであるが、ＧＯＰの整数に等しいような大きな値に設定することもできる。この場合、ステップ順送り及びステップ逆送りの両方とも可能である。何故なら、Ｉフレームのみが使用されるからである。
【００６５】
スロー順送りは、各フレームの繰り返しに基づくものとすることもでき、これは一層滑らかなスローモーションとなる。スロー順送りの最良の形態は、実際には、フレームの代わりにフィールドの繰り返しであろう。何故なら、時間解像度が倍となり、インターレースアーチファクトが存在しないからである。しかしながら、これは本来的にフレームに基づくＭＰＥＧ２ストリームに対しては事実上不可能であり、大幅に暗号化されている場合は一層そうである。インターレースアーチファクトは、Ｉ及びＰフレームに関しては、繰り返しを強制するための特別な空のフレームを用いることにより大幅に低減することができる。もっとも、このようなインターレース低減技術は、Ｂフレームに対しては利用可能ではない。Ｉ及びＰフレームに対するインターレース除去の使用が、この場合において依然として有利であるか、又は視聴者にとり実際に一層不快な画像となるかは実験によってのみ検証し得る。
【００６６】
時間的予測故に、個々のフレームに基づくスロー逆送りはＭＰＥＧ信号にとっては実際には非常に複雑となる。完全なＧＯＰが、バッファリングされ、且つ、反転されねばならない。知り得る限り、ＧＯＰにおけるフレームを逆の順序に再符号化する簡単な方法は存在しない。従って、略完全な復号及び符号化が、これら２つの間におけるフレーム順序の反転と共に必要となる。これは、完全な復号されたＧＯＰのバッファリング並びにＭＰＥＧデコーダ及びエンコーダを必要とする。
【００６７】
静止画モードは、フレームに基づくスロー順送りモードの拡張と定義することができる。これは、当該フレームのタイプが何であれ、静止画モードの期間にわたる現フレームの繰り返し表示に基づくものである。これは、スローモーション係数が、通常プレイストリームが低速化される係数を示すものであるならば、実際には無限のスローモーション係数によるスロー順送りである。Ｂフレームで画像が停止された場合、インターレース除去は可能ではない。その意味では、この静止画モードは、トリックプレイＧＯＰに基づく静止画モードより悪い。これは、幾らか静止画の位置の精度が劣ることを犠牲にして、Ｉ又はＰフレームで画像を停止させることによってのみ訂正することができる。この場合、ＰＴＳ及び時間基準の不連続も回避することができる。更に、ビットレートも大幅に低減される。何故なら、Ｂフレームに対して必要とされるようにフレームデータ自体の繰り返しの代わりに、空のフレームの挿入によりＩ又はＰフレームの繰り返しが強制されるからである。従って、技術的に言って、Ｉ又はＰフレームにおける画像の停止は最良の選択である。
【００６８】
上記静止画モードは、ステップモードで拡張することもできる。ステップコマンドは、当該ストリームを基本的に次のフレームに進める。次のＰフレーム又は何れかの次のＩフレームへのステップ動作により大きなステップサイズが可能となる。フレームに基づくステップ逆送りは可能ではない。唯一のオプションは、前のＩフレームのうちの１つへのステップ逆送りである。
【００６９】
以上、２つのタイプの静止画モード、即ちトリックプレイＧＯＰに基づくもの及びフレームに基づくものに言及した。最初のものは高速順送り／逆送りに略論理的に関連する一方、２番目のものはスロー順送りに関係している。何らかのモードから静止画に切り換える場合、切り換え遅れを最小にするために、関係する静止画モードを選択することが好ましい。両方法から得られるストリームは非常に似ている。何故なら、これらは共に、アンカフレームの繰り返しを強制するための空フレームの挿入に基づいているからである。しかしながら、詳細なストリーム構成レベルでは、幾つかの差が存在する。
【００７０】
以下においては、ＣＰＩ（"特徴点情報"）ファイルに関係する幾つかの態様を説明する。
【００７１】
ストリーム内のＩフレームを見つける処理は、通常は、フレームヘッダを見つけるために当該ストリームの解析を必要とする。Ｉフレームが開始する位置を突き止めることは、記録がなされている間に、又は記録が完了した後にオフラインで、又は半オンライで、実際にはオフラインであるが記録の時点に対して小さな遅延で、実施することができる。Ｉフレームの終了部は、次のＰフレーム又はＢフレームの開始を検出することにより見つけることができる。このようにして導出されたメタデータは、特徴点情報ファイル又はＣＰＩファイルと称することが可能な別個ではあるが結合されたファイルに記憶することができる。このファイルは、トランスポートストリームファイルにおける各Ｉフレームの開始部及び結果的に終了部に対するポインタを含むことができる。個々の記録は、自身のＣＰＩファイルを有することができる。
【００７２】
特徴点情報ファイル４００の構造が図４に示されている。
【００７３】
ＣＰＩファイル４００とは別に、記憶された情報４００も示されている。ＣＰＩファイル４００は、ここでは説明しない幾つかの他のデータも含むことができる。
【００７４】
ＣＰＩファイル４００からのデータにより、当該ストリームにおける如何なるＩフレーム２０１の開始部へのジャンプも可能となる。該ＣＰＩファイル４００がＩフレーム２０１の終了部も含んでいる場合、完全なＩフレーム２０１を得るために、当該トランスポートストリームファイルから読み取るべきデータの量も正確にわかる。何らかの理由により当該Ｉフレームの終了部がわからない場合、全体のＩフレーム２０１が読み取られることを確実にするために、全体のＧＯＰ又は当該ＧＯＰデータの少なくとも大部分が読み取られねばならない。当該ＧＯＰの終了部は、次のＩフレーム２０１の開始部により与えられる。測定から、Ｉフレームデータの量は全ＧＯＰデータの４０％以上であり得ることがわかる。
【００７５】
トリックプレイの画像リフレッシュレートの低減は各Ｉフレーム２０１を数回表示することにより達成することができることが知られている。それに応じてビットレートが低減される。これは、Ｉフレーム２０１の間に所謂空Ｐフレーム２０２を追加することにより達成することができる。このような空Ｐフレーム２０２は、実際には空ではなく、当該デコーダに前のフレームを繰り返すように命令するデータを含むことができる。これは限られたビットの犠牲しか有さず、多くの場合、Ｉフレームと比較して無視することができる。実験から、ＩＰＰ又はＩＰＰＰ等のトリックプレイＧＯＰ構造は、トリックプレイの画像品質にとって許容することができ、高いトリックプレイ速度では有利でさえあり得ることが知られている。結果としてのトリックプレイのビットレートは、通常プレイのビットレートのものと同程度である。これらの構造が記憶装置からの必要とされる持続帯域幅を低減し得ることも言及されている。
【００７６】
ここで、タイミングの問題及びストリーム構造に関する幾つかの態様を説明する。
【００７７】
トリックプレイシステム５００が図５に概念的に示されている。
【００７８】
トリックプレイシステム５００は、記録ユニット５０１と、Ｉフレーム選択ユニット５０２と、トリックプレイ発生ブロック５０３と、ＭＰＥＧ２デコーダ５０４とを有している。トリックプレイ発生ブロック５０３は、解析ユニット５０５と、加算ユニット５０６と、パケタイザユニット５０７と、テーブルメモリユニット５０８と、マルチプレクサ５０９とを含んでいる。
【００７９】
記録ユニット５０１は、Ｉフレーム選択ユニット５０２に平文ＭＰＥＧ２データ５０１を供給する。マルチプレクサ５０９はＭＰＥＧ２デコーダ５０４にＭＰＥＧ２ ＤＶＢ準拠のトランスポートストリーム５１１を供給する。
【００８０】
Ｉフレーム選択器５０２は、記憶装置５０１から特定のＩフレーム２０１を読み取る。どのＩフレーム２０１が選択されるかは、以下に説明するようにトリックプレイ速度に依存する。取り出されたＩフレーム２０１はＭＰＥＧ２／ＤＶＢ準拠のトリックプレイストリームを構築するために使用され、該ストリームは次いで復号及びレンダリングのためにＭＰＥＧ２デコーダ５０４に送られる。
【００８１】
上記トリックプレイストリームにおけるＩフレームパケットの位置は、元のトランスポートストリームの相対タイミングと結びつけることはできない。トリックプレイにおいては、時間軸は速度係数により圧縮又は伸張され得、更に逆送りトリックプレイのために反転され得る。従って、元のタイムスタンプ付けされたトランスポートストリームのタイムスタンプはトリックプレイの発生には適さないであろう。
【００８２】
更に、元のＰＣＲタイムベースはトリックプレイに対して妨害的となり得る。先ず、ＰＣＲが、選択されたＩフレーム２０１内で利用可能であることは保証されない。しかしながら、もっと重要なことは、ＰＣＲタイムベースの周波数が変化されることであろう。ＭＰＥＧ２仕様によれば、この周波数は２７ＭＨｚから３０ｐｐｍ内でなければならない。元のＰＣＲタイムベースは、この要件を満たすが、トリックプレイに使用された場合、トリックプレイ速度係数により乗算されるであろう。逆送りトリックプレイの場合、これは間違った方向に走るタイムベースとさえなる。従って、古いタイムベースは削除されねばならず、あらたしいものがトリックプレイストリームに追加されねばならない。
【００８３】
最後に、Ｉフレーム２０１は、通常、デコーダ５０４に対し何時当該フレーム開始すべきか（復号タイムスタンプ、ＤＴＳ）及び該フレームを何時提示（例えば表示）開始すべきか（提示タイムスタンプ、ＰＴＳ）を告げる２つのタイムスタンプを含んでいる。復号及び提示は、ＤＴＳ及びＰＴＳが、デコーダ５０４内で当該ストリームにおけるＰＣＲにより再生されたＰＣＲタイムベースに等しい場合に開始することができる。例えば２つのＩフレーム２０１のＰＣＲ値の間の距離は、それらの表示時間の通常の距離に対応する。トリックプレイにおいては、この時間距離は速度係数により圧縮又は伸張される。トリックプレイにおいては新たなＰＣＲタイムベースが使用され、ＤＴＳ及びＰＴＳに関する距離は、最早、正しくないので、Ｉフレーム２０１の元のＤＴＳ及びＰＴＳは置換されねばならない。
【００８４】
上述した複雑さを解決するために、Ｉフレーム２０１は先ず解析ユニット５０５において基本ストリーム（エレメンタリストリーム）に分解することができる。次いで、基本ストリームレベルにおいて空のＰフレーム２０２が追加される。得られたトリックプレイＧＯＰは１つのＰＥＳパケットにマッピングされ、トランスポートストリームパケットにパケット化される。次いで、ＰＡＴ、ＰＭＴ等の補正されたテーブルが追加される。この段階において、新しいＰＣＲタイムベースがＤＴＳ及びＰＴＳと一緒に含まれる。トランスポートストリームパケットには、当該トリックプレイストリームが通常プレイに使用されるのと同一の出力回路により処理され得るように、ＰＣＲタイムベースに結合された４バイトのタイプストリームが前に添付される。
【００８５】
以下においては、トリックプレイ速度に関連する幾つかの態様を説明する。この状況において、先ず、固定のトリックプレイ速度を説明する。
【００８６】
前述したように、Ｉフレーム２０１に２つの空のＰフレーム２０２が後続するようなＩＰＰ等のトリックプレイＧＯＰ構造を使用することができる。元のＧＯＰは１２フレームのＧＯＰサイズ２０３を有し、元の全てのＩフレーム２０１がトリックプレイに使用されると仮定する。これは、通常プレイストリームにおけるＩフレーム２０１は１２フレームの距離を有し、トリックプレイストリームにおける同じＩフレーム２０１は３フレームの距離を有することを意味する。これは、１２／３＝４なるトリックプレイ速度となる。元のＧＯＰのフレームでのサイズ２０３がＧにより、トリックプレイＧＯＰのフレームでのサイズがＴにより、トリックプレイ速度係数がＮｂにより各々示された場合、一般的にトリックプレイ速度は、
Ｎｂ＝Ｇ／Ｔ （１）
により与えられる。
【００８７】
Ｎｂは基本速度とも呼ばれる。一層早い速度は、元のストリームからＩフレーム２０１をスキップすることにより実現することができる。２つ目毎のＩフレーム２０１がとられた場合、トリックプレイ速度は倍となり、３つ目毎のフレームがとられた場合、トリックプレイ速度は３倍となり、等々となる。言い換えると、元のストリームにおける使用されるＩフレーム２０１の間の距離は２、３等となる。この距離は常に整数であり得る。トリックプレイの発生に使用されるＩフレーム２０１の間の距離がＤにより示される場合（Ｄ＝１は全Ｉフレーム２０１が使用されることを意味する）、一般的トリックプレイ速度係数Ｎは、
Ｎ＝Ｄ＊Ｇ／Ｔ （２）
により与えられる。
【００８８】
これは、基本速度の全ての整数倍を実現することができ、許容可能な速度の組となることを意味する。逆送りトリックプレイに対してはＤが負となり、Ｄ＝０は静止画となることに注意されたい。データは順方向においてのみ読み取ることができる。従って、逆送りトリックプレイにおいては、データは順方向に読み取られ、Ｄにより与えられる先行するＩフレーム２０１を取り出すために逆方向へのジャンプがなされる。大きなトリックプレイＧＯＰサイズＴが一層遅い基本速度になることにも注意されたい。例えば、ＩＰＰＰはＩＰＰよりも一層細かな粒度の速度組になる。
【００８９】
図６を参照して、トリックプレイにおける時間圧縮を説明する。
【００９０】
図６は、Ｔ＝３（ＩＰＰ）及びＧ＝１２の状況を示している。Ｄ＝２の場合、２４フレームの元の表示時間は、３フレームのトリックプレイ表示時間に圧縮され、結果としてＮ＝８となる。与えられた例において、基本速度は整数であるが、これが必ずしも当てはまるわけではない。Ｇ＝１６及びＴ＝３の場合、基本速度は１６／３＝５及び１／３となり、これは整数トリックプレイ速度の組とはならない。従って、１６なるＧＯＰサイズに対してはＩＰＰＰ構造（Ｔ＝４）の方が一層適しており、結果として４ｘなる基本速度となる。１２及び１６なる最も普通のＧＯＰサイズに適合する単一のトリックプレイ構造が望ましい場合、ＩＰＰＰを選択することができる。
【００９１】
次に、任意のトリックプレイ速度を説明する。
【００９２】
幾つかの場合においては上述した方法から得られるトリックプレイ速度の組が満足のいくものとなるが、幾つかの場合においてはそうではない。Ｇ＝１６及びＴ＝３の場合、依然として整数のトリックプレイ速度係数を好む場合もあり得る。Ｇ＝１２及びＴ＝４の場合でさえ、例えば７ｘ等の当該組においては利用可能でない速度を有することが好まれ得る。ここで、前記トリックプレイ速度方程式が反転され、距離Ｄが計算されるが、これは、
Ｄ＝Ｎ＊Ｔ／Ｇ （３）
により与えられる。
【００９３】
Ｇ＝１２、Ｔ＝４及びＮ＝７なる上記例を用いると、Ｄ＝２ １／３となる。固定数のＩフレーム２０１をスキップする代わりに、次のＩフレーム２０１を何のＩフレーム２０１が所要の速度に最良に適合するかの事実に基づいて選択するような適応的スキップアルゴリズムを使用することができる。最良に適合するＩフレーム２０１を選択するために、距離Ｄを持つ次の理想点Ｉｐを計算することができ、Ｉフレーム２０１のうちの、この理想点に最も近い１つを選択して、トリックプレイＧＯＰを構築することができる。続くステップにおいては、最後の理想点をＤだけ増加させることにより、次の理想点を再び計算することができる。
【００９４】
断片的距離でトリックプレイを図示する図７に示されるように、特にＩフレーム２０１を選択する３つの可能性が存在する。即ち、
Ａ．理想点に最も近いＩフレーム；Ｉ＝round(Ip)
Ｂ．理想点より前の最後のＩフレーム；Ｉ＝int(Ip)
Ｃ．理想点より後の最初のＩフレーム；Ｉ＝int(Ip)+1
である。
【００９５】
明らかにわかるように、実際の距離はint(D)とint(D)+1との間で変化し、２つの発生の間の比は、平均距離がＤに等しくなるようにＤの分数に依存する。これは、平均トリックプレイ速度はＮに等しいが、実際に使用されるフレームは理想のフレームに対して小さなジッタを有することを意味する。これに関して幾つかの実験が実行されたところ、トリックプレイ速度は局部的に変化し得るが、これは視覚的に乱すものではない。普通には、特に幾らか高いトリックプレイ速度では目立つことさえない。図７からは、方法Ａ、Ｂ又はＣの何れを選んでも本質的な差はないことも明らかである。
【００９６】
この方法によれば、トリックプレイ速度Ｎは整数である必要はなく、基本速度Ｎｂより大きな如何なる値とすることもできる。この最小値より低い速度も選択することができるが、その場合、画像リフレッシュレートが局部的に低下され得る。何故なら、実効的トリックプレイＧＯＰサイズが倍になるか、更に低い速度では３倍又はそれ以上になるからである。これはトリックプレイＧＯＰの繰り返しによる。というのは、当該アルゴリズムが同一のＩフレーム２０１を２回以上選択するからである。
【００９７】
図８は、Ｎ＝２／３・Ｎｂと等価のＤ＝２／３の例を示している。ここでは、Ｉフレーム２０１を選択するために丸め関数が使用され、見られるように、フレーム２及び４が２回選択される。
【００９８】
何れにしろ、上述した方法は連続的に変化可能なトリックプレイ速度を可能にする。逆送りトリックプレイの場合、Ｎに対して負の値が選択される。図７の例の場合、これは、単に矢印７００が逆の方向を指すことを意味する。上述した方法は、先に言及した固定のトリックプレイ速度の組も含み、これらは、特に丸め関数が使用された場合、同じ品質を有するであろう。従って、この節で述べた柔軟な方法は速度の選択がどの様であれ常に実施化されるべきであることが適切であろう。
【００９９】
ここで、トリックプレイ画像のリフレッシュレートに関する幾つかの態様を説明する。
【０１００】
"リフレッシュレート"なる用語は、特に、新しい画像が表示される周波数を指す。速度依存的ではないが、Ｔの選択に影響を与え得るので、ここでは簡単に述べる。元の画像のリフレッシュレートがＲ（２５Ｈｚ又は３０Ｈｚ）により示される場合、トリックプレイ画像のリフレッシュレート（Ｒｔ）は、
Ｒｔ＝Ｒ／Ｔ （４）
により与えられる。
【０１０１】
ＩＰＰ（Ｔ＝３）又はＩＰＰＰ（Ｔ＝４）のトリックプレイＧＯＰ構造によれば、リフレッシュレートＲｔは、ヨーロッパでは各々８1/3Ｈｚ又は６1/4Ｈｚとなり、米国では各々１０Ｈｚ又は７1/2Ｈｚとなる。トリックプレイ画像の品質の判定は幾らかは主観的事項であるが、実験から、これらリフレッシュレートは低い速度では許容可能であり、高い速度では更に有利であるとの明らかな手がかりが存在する。
【０１０２】
以下においては、暗号化されたストリーム環境に関する幾つかの態様を説明する。
【０１０３】
ここで、暗号化されたストリーム上でのトリックプレイの説明のための基礎として、暗号化されたトランスポートストリームについての幾らかの情報を示す。放送用に使用される条件付きアクセスシステム（Conditional Access System）に焦点を合わせる。
【０１０４】
図９は、ここで説明する条件付きアクセスシステム９００を示す。
【０１０５】
該条件付きアクセスシステム９００において、コンテンツ９０１はコンテンツ暗号化ユニット９０２に供給することができる。コンテンツ９０１を暗号化した後、コンテンツ暗号化ユニット９０２はコンテンツ解読ユニット９０４に暗号化されたコンテンツ９０３を供給する。この明細書において、ＥＣＭは権限制御メッセージ（Entitlement Control Message）を指すと述べた。更に、ＫＭＭはキー管理メッセージ（Key Management Message）を指し、ＧＫＭはグループキーメッセージ（Group Key Message）を指し、ＥＭＭは権限管理メッセージ（Entitlement Management Message）を指すものとする。制御ワード９０６をコンテンツ暗号化ユニット９０２及びＥＣＭ発生ユニット９０７に供給することができる。ＥＣＭ発生ユニット９０７はＥＣＭを発生し、同ＥＣＭをスマートカード９０５のＥＣＭ復号ユニット９０８に供給する。ＥＣＭ復号ユニット９０８は上記ＥＣＭから制御ワードを発生し、該制御ワードは暗号化されたコンテンツ９０３を解読するために必要とされる解読情報で、コンテンツ解読ユニット９０４に供給される。
【０１０６】
更に、許可キー（authorization key）９１０がＥＣＭ発生ユニット９０７及びＫＭＭ発生ユニット９１１に供給され、その場合において、後者はＫＭＭを発生し、同ＫＭＭをスマートカード９０５のＫＭＭ復号ユニット９１２に供給する。ＫＭＭ復号ユニット９１２は出力信号をＥＣＭ復号ユニット９０８に供給する。
【０１０７】
更に、グループキー９１４をＫＭＭ発生ユニット９１１及びＧＫＭ発生ユニット９１５に供給することができ、ＧＫＭ発生ユニット９１５には更にユーザキー９１８を供給することができる。ＧＫＭ発生ユニット９１５はＧＫＭ信号ＧＫＭを発生すると共に、同ＧＫＭ信号をスマートカード９０５のＧＫＭ復号ユニット９１６に供給し、該ＧＫＭ復号ユニット９１６は更なる入力としてユーザキー９１７を得る。
【０１０８】
更に、エンタイトルメント（権限）９１９をＥＭＭ発生ユニット９２０に供給することができ、該ＥＭＭ発生ユニットはＥＭＭ信号を発生すると共に同信号をＥＭＭ復号ユーザ９２１に供給する。スマートカード９０５内に位置する上記ＥＭＭ復号ユニット９２１は権限リストユニット９１３に結合されており、該権限リストユニットはＥＣＭ復号ユニット９０８に対応する制御情報を供給する。
【０１０９】
多くの場合において、コンテンツプロバイダ及びサービスプロバイダは、条件付きアクセス（ＣＡ）システムを介して、特定のコンテンツ項目へのアクセスを制御したいと欲する。
【０１１０】
これを達成するために、放送されるコンテンツ９０１はＣＡシステム９００の制御の下で暗号化される。受信機において、コンテンツは、ＣＡシステム９００によりアクセスが許可されたなら、復号及びレンダリングする前に解読される。
【０１１１】
ＣＡシステム９００は層状の階層構造を使用する（図９参照）。ＣＡシステム９００はコンテンツ解読キー（制御ワードＣＷ９０６，９０９）をサーバからクライアントへＥＣＭと呼ばれる暗号化されたメッセージの形態で転送する。ＥＣＭは許可キー（ＡＫ）９１０を使用して暗号化されている。安全保護の理由で、ＣＡサーバ９００は許可キー９１０を、ＫＭＭを発行することにより更新する。実際には、ＫＭＭは特別なタイプのＥＭＭであるが、明瞭化のために、ＫＭＭなる用語を使用する。ＫＭＭも、例えばグループキー（ＧＫ）９１４とすることが可能なキーを用いて暗号化されており、該グループキーは、これも特別なタイプのＥＭＭであるＧＫＭを送ることにより更新される。この場合、ＧＫＭはユーザキー（ＵＫ）９１７，９１８により暗号化され、該ユーザキーはスマートカード９０５に埋め込まれ、当該プロバイダのＣＡシステム９００によってのみ知られた固定の固有のキーである。許可キー及びグループキーは、受信機のスマートカード９０５内に記憶される。
【０１１２】
エンタイトルメント９１９（例えば、視聴権）は、個々の顧客にＥＭＭの形態で送信され、安全保護装置（スマートカード９０５）にローカルに記憶される。エンタイトルメント９１９は特定の番組（プログラム）に結合される。権限リスト９１３は、契約のタイプに応じて一群の番組に対するアクセスを与える。ＥＣＭは、エンタイトルメント９１９が特定の番組に対して利用可能である場合にのみ、スマートカード９０５によりキー（制御ワード）へと処理される。エンタイトルメントＥＭＭは、ＫＭＭと同じ層状構造に従う（図９には示されていない）。
【０１１３】
ＭＰＥＧ２システムにおいては、暗号化されたコンテンツＥＣＭ及びＥＭＭ（ＫＭＭ及びＧＫＭタイプを含む）は、全て単一のＭＰＥＧ２トランスポートストリームに多重化される。上述した説明は、ＣＡシステム９００の概要である。デジタルビデオ放送においては、暗号化アルゴリズム、奇数／偶数制御ワード構造、ＥＣＭ及びＥＭＭの全体構造並びにそれらの参照が規定される。ＣＡシステム９００の詳細な構造並びにＥＣＭ及びＥＭＭのペイロードが符号化及び使用される方法は、プロバイダに固有のものである。また、スマートカードもプロバイダ固有である。しかしながら、経験から、多くのプロバイダが図９の概要図のような構造に本質的に従っていることが分かっている。
【０１１４】
以下においては、ＤＶＢ暗号化／解読の主たる題目を説明する。
【０１１５】
適用される暗号化及び解読アルゴリズムは、ＤＶＢ標準化組織により規定される。原則的に、２つの暗号化の可能性、即ちＰＥＳレベル暗号化及びＴＳレベル暗号化が規定される。しかしながら、実世界では、主にＴＳレベル暗号化が使用されている。トランスポートストリームパケットの暗号化及び解読は、パケットに基づいてなされる。これは、暗号化及び解読アルゴリズムが、新たなトランスポートストリームパケットが受信される毎に再開されることを意味する。従って、パケットは個別に暗号化又は解読することができる。トランスポートストリームにおいては、暗号化された及び平文のパケットが混合されている。何故なら、幾つかのストリーム部分は暗号化され（例えば、オーディオ／ビデオ）、他のものは暗号化されない（例えば、テーブル）からである。１つのストリーム部分（例えば、ビデオ）内でさえ、暗号化された及び平文のパケットが混合され得る。
【０１１６】
図１０を参照して、ＤＶＢ暗号化トランスポートストリームパケット１０００を説明する。
【０１１７】
ストリームパケット１０００は、１８８バイトの長さ１００１を有し、３つの部分を含んでいる。パケットヘッダ１００２は４バイトのサイズ１００３を有している。パケットヘッダ１００２に続いて、当該ストリームパケット１０００にはアダプテーションフィールド１００４が含まれ得る。その後に、ＤＶＢ暗号化パケットペイロード１００５を送信することができる。
【０１１８】
図１１は、図１０のトランスポートストリームパケットのヘッダ１００２の詳細な構造を示している。
【０１１９】
トランスポートストリームパケットヘッダ１００２は、同期ユニット（ＳＹＮＣ）１０１０と、パケット内のトランスポートエラーを示すことが可能なトランスポートエラーインジケータ（ＴＥＩ）１０１１と、特に後続のペイロード１００５におけるＰＥＳパケットの可能性のある開始部を示すことができるペイロードユニット開始インジケータ（PLUSI）１０１２と、当該トランスポートの優先度を示すトランスポート優先度ユニット（ＴＰＩ）１０１７と、当該パケットの任務（assignment）を決定するために使用されるパケット識別子（ＰＩＤ）１０１３と、当該トランスポートストリームパケットを解読するために要するＣＷを選択するために使用されるトランスポートスクランブル制御子（ＳＣＢ）１０１４と、アダプテーションフィールド制御子（ＡＦＬＤ）１０１５と、継続カウンタ（ＣＣ）１０１６とを有している。このように、図１０及び図１１は、暗号化されているＭＰＥＧ２トランスポートストリームパケットを示しており、該パケットは異なる部分を有している。即ち、
− パケットヘッダ１００２は平文である。該ヘッダは、パケット識別子（ＰＩＤ）番号、アダプテーションフィールドの存在、スクランブル制御ビット等の重要な情報を得るように働く。
− アダプテーションフィールド１００４も平文である。該フィールドはＰＣＲ等の重要なタイミング情報を含み得る。
− ＤＶＢ暗号化パケットペイロード１００５は、ＤＶＢアルゴリズムを使用して暗号化されている可能性のある実際の番組コンテンツを含む。
【０１２０】
放送された番組を解読するために要する正しいＣＷを選択するために、トランスポートストリームパケットヘッダを解析することが必要となる。このヘッダの概要が、図１１に示されている。放送された番組の解読にとり重要なフィールドは、スクランブル制御ビット（ＳＣＢ）フィールド１０１４である。このＳＣＢフィールド１０１４は、解読器が、放送された番組を解読するために何のＣＷを使用しなければならないかを示す。更に、該フィールドは、当該パケットのペイロードが暗号化されているか又は平文であるかを示す。全ての新しいトランスポートストリームパケットに対して、このＳＣＢ１０１４は解析されねばならない。何故なら、該ＳＣＢは時間にわたり変化し、パケット毎に変化し得るからである。
【０１２１】
以下においては、完全に暗号化されたストリーム上でのトリックプレイに関する幾つかの態様を説明する。
【０１２２】
これが関心のある主題であるという第１の理由は、平文上でのトリックプレイ及び完全に暗号化されたストリーム上でのトリックプレイは、一連の可能性における両極端であるからである。他の理由は、完全に暗号化されたストリームを記憶する必要があり得るようなアプリケーションが存在するからである。かくして、完全に暗号化されたストリーム上でトリックプレイを実行する技術を有することは有用なことであろう。基本原理は、記憶装置から十分に大きなブロックのデータを読み取り、これを解読し、該ブロック内のＩフレームを選択し、これを用いてトリックプレイストリームを構築することである。
【０１２３】
斯様なシステム１２００が図１２に示されている。
【０１２４】
図１２は、完全に暗号化されたストリームに対するトリックプレイの基本原理を示す。この目的のために、ハードディスク１２０１上に記憶されたデータが解読器１２０３にトランスポートストリーム１２０２として供給される。更に、ハードディスク１２０１はスマートカード１２０４にＥＣＭを供給し、その場合において、該スマートカード１２０４は該ＥＣＭから制御ワードを発生し、同制御ワードを解読器１２０３に送出する。
【０１２５】
上記制御ワードを使用して、解読器１２０３は前記暗号化されたトランスポートストリーム１２０２を解読し、解読されたデータをＩフレーム検出器及びフィルタ１２０５に送出する。そこから、上記データは空Ｐフレーム挿入ユニット１２０６に供給され、該ユニットは該データをセットトップボックス１２０７に伝達する。そこから、データはテレビジョン１２０８に供給される。
【０１２６】
記録が何を含むかの問題に関して幾つかの態様を説明する。
【０１２７】
単一チャンネルの記録を行う場合、該記録は該チャンネルの記録を後の段階で再生するために要する全てのデータを含まなければならない。特定の応答器に全てを記録することだけに頼ることもできるが、この方法では、記録したい番組を再生するのに必要なものより遙かに多くを記録することになる。これは、帯域幅及び記憶空間の両者が浪費されることを意味する。従って、こうする代わりに、本当に必要なパケットのみが記録されるべきである。これは、各番組に関して、ＰＡＴ（プログラム・アソシエーション（関連）・テーブル）、ＣＡＴ（条件付きアクセステーブル）等の全てのＭＰＥＧ２に必須のパケット、並びに明らかなことに各番組に対してビデオ及びオーディオパケット並びに何のパケットが番組に属するかを記述したＰＭＴ（プログラム・マップ・テーブル）を記録せねばならないことを意味する。更に、上記ＣＡＴ／ＰＭＴは当該ストリームの解読に要するＣＡパケット（ＥＣＭ）を記述することができる。記録が解読の後に平文でなされない限り、これらＥＣＭパケットも記録されねばならない。
【０１２８】
なされた記録が、完全な多重からの全てのパケットから構成されない場合、当該記録は所謂部分トランスポートストリーム１３００（図１３参照）となる。更に、図１３は完全なトランスポートストリーム１３０１も示す。ＤＶＢ規格は、部分トランスポートストリーム１３００が再生される場合、ＮＩＴ（ネットワーク情報テーブル）、ＢＡＴ（ブーケ・アソシエーション・テーブル）等の全ての通常のＤＶＢ必須テーブルが削除されることを求めている。これらのテーブルの代わりに、部分ストリームはＳＩＴ（選択情報テーブル）及びＤＩＴ（不連続情報テーブル）テーブルが挿入されるようにしなければならない。
【０１２９】
以下では、ＥＣＭの処理に関する幾つかの態様を説明する。
【０１３０】
トリックプレイの間において次のブロックへジャンプすることは、当該ストリームにおいて逆にジャンプすることを意味し得る。これは、トリックプレイ逆送りの場合のみならず、緩やかな速度におけるトリックプレイ順送りの場合でもあり得ると説明されるであろう。順方向ジャンプによる順方向トリックプレイ及び本来の逆方向ジャンプによる逆方向トリックプレイに関する状況は後に説明する。
【０１３１】
データが解読されねばならないという事実に起因して、固有の問題が発生し得る。条件付きアクセスシステムは、送信のために設計することができる。通常プレイにおいて、送信されたストリームは元のタイミングで再構築することができる。しかしながら、トリックプレイは、変化されたタイミングにより暗号的メタデータの処理に関して厳しい意味を有し得る。データはトリックプレイにより時間的に圧縮又は伸張され得るが、スマートカードのレイテンシは一定に留まり得る。
【０１３２】
トリックプレイストリームを形成するために、前述したデータブロックは解読器を通過し得る。この解読器は、当該データブロックを解読するために、暗号化処理に使用された制御ワードを必要とする。これらの制御ワードも、暗号化されＥＣＭに記憶され得る。通常のセットトップボックス（ＳＴＢ）では、これらのＥＣＭは同調された番組の一部であり得る。条件付きアクセス（限定受信）モジュールは、斯かるＥＣＭを抽出し、スマートカードに送出することができ、このカードが斯かるＥＣＭを解読する権利又は権能（authorization）を有するなら、該カードから解読された制御ワードを入力することができる。制御ワードは、通常は、例えば約１０秒等の相対的に短い寿命しか有さない。この寿命は、トランスポートストリームパケットのヘッダにおけるスクランブル制御ビットＳＣＢ１０１４により示すことができる。これが変化した場合、次の制御ワードが使用されねばならない。このＳＣＢの変化又はトグルが、図１４に垂直線により符号１４０２で示されている。
【０１３３】
図１４を参照すると、特に２つの異なる筋書き又はストリームタイプを区別することができる。
【０１３４】
図１４の下側の行に示されるストリームタイプＩによれば、ＥＣＭ当たり２つの制御ワード（ＣＷ）が供給される。
【０１３５】
図１４の上側の行に示されるストリームタイプIIによれば、ＥＣＭ当たり１つのみの制御ワード（ＣＷ）が供給される。
【０１３６】
図１４は、符号１４０３により示された連続して配列された期間又は区間Ａ，Ｂ，Ｃを有する２つのデータストリームを示している。図１４の上側の行１４００に示された筋書きでは、対応するＥＣＭ当たり本質的に１つの制御ワードが供給される。これとは対照的に、下側の行１４０１では、各ＥＣＭは２つの制御ワード、即ち現期間又はＥＣＭに関する制御ワード及び、更に、後続の期間又はＥＣＭの制御ワードを有する。このように、これら制御ワードの供給に関して幾らかの冗長性が存在する。
【０１３７】
前記短い寿命期間の間において、解読情報の項目は何回が送信することができるので、斯様な制御ワードの寿命期間を経る途中で斯様なチャンネルへ同調することは、次の制御ワードを待つことを意味しない。当該条件付きアクセスモジュールは、見つけた最初の固有のＥＣＭのみをスマートカードに送出して該カードに対するトラフィックを低減又は最少化する。というのは、斯かるカードは、かなり遅いプロセッサを有し得るからである。
【０１３８】
このことは、暗号化されたストリームに対するトリックプレイの限界が存在し得ることを示している。そこには、スマートカードの処理能力の限定された速度に由来する暗黙的上限速度が存在し得る。トリックプレイにおいて、１０秒なる制御ワード寿命はトリックプレイ速度係数により圧縮又は伸張され得る。ＥＣＭをスマートカードに送出すると共に解読された制御ワードを受け取るには、約半秒掛かり得る。制御ワードがＥＣＭに詰め込まれる方法はプロバイダ固有のものであり得、図１４に示されるように、ストリームタイプＩ及びストリームタイプIIに関して特に異なり得る。
【０１３９】
ＣＷ Ａは期間Ａを暗号化するために使用されたＣＷを示し、ＣＷ Ｂは期間Ｂを暗号化するために使用されたＣＷを示し、等々である。水平方向に、送信時間軸がプロットされている。ＥＣＭ Ａは、期間Ａの大部分の間に存在するＥＣＭであると定義することができる。その場合、ＥＣＭ Ａは現期間Ａのための、及びストリームタイプＩに関しては更に次の期間ＢのためのＣＷを保持することがわかる。一般的に、ＥＣＭは現期間のためのＣＷを少なくとも保持することができると共に、次の期間のためのＣＷを保持することができる。ザッピングのために、これは恐らく全ての又は多くのプロバイダにとり当てはまるであろう。
【０１４０】
更に続ける前に、解読器及び該解読器がＣＷをどの様に処理することができるかに関しての更なる情報を示す。解読器は２つのレジスタ、即ち"奇数"ＣＷ用のもの及び"偶数"ＣＷ用のものを含むことができる。"奇数"及び"偶数"は、ＣＷの値自体が奇数又は偶数であることを意味する必要はない。斯かる用語は、当該ストリームにおける２つの連続するＣＷの間を区別するために特に使用される。何のＣＷがパケットの解読に使用されるべきかは、パケットヘッダにおけるＳＣＢ１０１４により示される。従って、当該ストリームを暗号化するために使用されるＣＷは奇数と偶数との間で交互となる。図１４において、これは、例えばＣＷ Ａ及びＣＷ Ｃは奇数である一方、ＣＷ Ｂ及びＣＷ Ｄは偶数となることを意味する。スマートカードによる解読の後、ＣＷは、図１５に示されるように、前の値に上書きして、解読器の対応するレジスタに書き込むことができる。
【０１４１】
図１５は、偶数ＣＷを含む（レジスタ１５０１）及び奇数ＣＷを含む（レジスタ１５０２）２つのレジスタ１５０１，１５０２を示している。更に、スマートカードのレイテンシ１５００（スマートカードによりＥＣＭからＣＷを取り出す又は解読するために要する時間である）も図１５に示されている。
【０１４２】
ストリームタイプＩの場合、各ＥＣＭは２つのＣＷを保持し、結果として、両レジスタ１５０１，１５０２がＥＣＭの解読の後に上書きされ得る。レジスタ１５０１，１５０２のうちの一方が活性状態となり、他方が不活性状態となる。どちらのものが活性状態となるかは、ＳＣＢ１０１４に依存する。本例では、ＳＣＢ１０１４は期間Ｂの間において偶数レジスタ１５０１が活性状態のものであることを示すであろう。活性状態レジスタのみが、既に保持しているものと同一のＣＷにより上書きされ得る。何故なら、当該特定の期間の残りの解読のために依然として必要とされるからである。従って、不活性状態のレジスタのみが、新たな値で上書きすることができる。
【０１４３】
トリックプレイにおける期間Ｂを詳細に調べる。ＥＣＭが、この期間の開始点において、従ってＳＣＢトグル１４０２が横断された時点でスマートカードに送られると仮定する。問題は、この場合、どのＥＣＭをスマートカードに送ることができるかである。
【０１４４】
このＥＣＭは、期間Ｃの開始時に使用するためのスマートカードによる適時の解読を保証するためにＣＷ Ｃを保持していなければならない。
【０１４５】
該ＥＣＭは、当該解読器におけるＣＷの正しい利用可能性を妨害することなしにＣＷ Ｂも保持することができる。
【０１４６】
再び図１４を見ると、これは、ストリームタイプＩの場合、期間Ｂの開始時にＥＣＭ Ｂを送ることを意味し、ストリームタイプIIの場合ＥＣＭ Ｃを送ることを意味することがわかる。一般的に、２つのＣＷを保持する場合、現ＥＣＭを送ることができ、１つのＣＷのみを保持する場合は１期間先行して送ることができる。ＥＣＭを１期間先行して送ることは、埋め込まれたＥＣＭとは相反し得るので、その場合、後者はストリームから除去されねばならない。もっと一般化された方法にとっては、元のＥＣＭがトリックプレイ発生回路又はソフトウェアによりストリームから常に削除されることが好ましいであろう。しかしながら、これが常に当てはまるとは限らない。
【０１４７】
図１６は、高速順送りモードにおけるＥＣＭ処理を示す。
【０１４８】
ＳＣＢトグル１４０２により分離される複数の連続する期間１４０３において、複数のデータブロック１６００が再生され、その場合において異なるブロックの間で切り換え１６０１が生じる。
【０１４９】
ストリームタイプＩの場合、期間Ａ及びＢの間の境界ではＥＣＭ Ｂが送出される。ストリームタイプIIの場合、期間Ａ及びＢの間の境界ではＥＣＭ Ｃが送出される。更に、ストリームタイプＩによれば、期間Ｂ及びＣの間の境界でＥＣＭ Ｃが送出される。ストリームタイプIIの場合、期間Ｂ及びＣの間の境界ではＥＣＭ Ｄが送出される。
【０１５０】
ＥＣＭが正しい時点でトリックプレイのために利用可能になるために、ＥＣＭは別のファイルに記憶することができる。このファイルでは、何の期間（記録されるストリームの何の部分）にＥＣＭが属するかを示すことができる。ＭＰＥＧストリームファイルにおけるパケットには、番号を付すことができる。期間における最初のパケット（ＳＣＢトグル１４０２）の番号は、この期間１４０３に対するＥＣＭと一緒に記憶することができる。ＥＣＭファイルは、ストリームの記録の間に発生することができる。
【０１５１】
ＥＣＭファイルは、記録の間に作成することが可能なファイルである。ストリームには、ビデオデータを解読するために要する制御ワードを含むことが可能なＥＣＭパケットを配置することができる。各ＥＣＭは特定の期間、例えば１０秒にわたり使用することができ、この期間の間に何回（例えば１００回）も（繰り返し）送信することができる。ＥＣＭファイルは、そのような期間の全ての最初の新しいＥＣＭを含むことができる。ＥＣＭデータは、このファイルに書き込むことができ、何らかのメタデータが付帯し得る。先ず、連続番号（１から計数する）が与えられ得る。第２フィールドとして、ＥＣＭファイルはＳＣＢトグルの位置を含むことができる。これは、このＥＣＭを自身のコンテンツを正しく解読するために使用することができる最初のパケットを指すことができる。この場合、このＳＣＢトグルの時間位置が第３のフィールドとして後続し得る。これらの３つのフィールドには、ＥＣＭパケットデータ自体が後続し得る。
【０１５２】
ＥＣＭファイルに記憶されたＳＣＢトグルを使用して、斯様なトグルが横断されたかを、これがジャンプの間であってさえも、容易に検出することができる。正しいＥＣＭを送るために、ＥＣＭが１つのＣＷを含むか又は２つのＣＷを含むかを知ることが必要とされ得る。基本的に、これはわからない。何故なら、それはプロバイダ固有のものであり、秘密であるからである。しかしながら、これは、ＥＣＭを種々の時点で送出し、表示器上の結果を観察することにより実験的に容易に判定することができる。記憶装置自体内で実施化するのに特に適した代替方法は、下記の通りである。ＳＣＢトグルの時点において単一のＥＣＭをスマートカードに送出し、当該ストリームを解読し、来たる２つの期間内でＰＥＳヘッダをチェックする。ＧＯＰ当たり１つのＰＥＳヘッダによれば、各期間内に約２０個のＰＥＳヘッダが存在する。ＰＥＳヘッダの位置は容易に検出することができる。何故なら、パケットの平文ヘッダ内のPLUSIビットが、その存在を示し得るからである。正しいＰＥＳヘッダが最初の期間（スマートカードのレイテンシの後の）の間でのみ見つかった場合、当該ＥＣＭは１つのＣＷを含む。これらが第２の期間の間でも見つかった場合は、当該ＥＣＭは２つのＣＷを含む。このような状況が、図１７に示される。
【０１５３】
図１７は、１つのＣＷの検出に対する及び２つのＣＷ検出に対する状況を示す。理解されるように、暗号化されたコンテンツ１７００の異なる期間１４０３が設けられる。スマートカードのレイテンシ１５００により、ＥＣＭ Ａは解読されて、対応するＣＷを発生することができる。暗号化されたコンテンツ１７００を解読することにより、解読されたコンテンツ１７０１を発生することができる。図１７に更に示されるものは、ＰＥＳヘッダ１７０２、即ち期間Ａ（左）におけるＰＥＳヘッダＡ及び期間Ｂ（右）におけるＰＥＳヘッダＢである。
【０１５４】
図１７における１つのＣＷの期間Ｂの領域１７０３は、当該データが間違ったキーで解読され、従ってスクランブルされることを示す。このチェックは、記録の間に実行することができ、その場合、例えば２０ないし３０秒掛かるであろう。これはオフラインで実行することもでき、PLUSIにより示される２つのパケットのみ（各期間において１つ）をチェックすればよいから、非常に高速であり得る。適切なＰＥＳヘッダが利用可能でないという、ありそうにない事象においては、代わりに画像ヘッダを使用することができる。事実、検出のためには如何なる既知の情報も使用することができる。いずれにせよ、１／２ＣＷ指示子をＥＣＭファイルに記憶することができる。
【０１５５】
以下においては、特にスロー順送りストリームの処理に関する幾つかの態様を説明する。
【０１５６】
次に、トリックプレイＧＯＰに基づくスロー順送り、静止画及びステップモードを説明する。
【０１５７】
スローモーション順送りとも称すことができるスロー順送りは、表示画像が通常よりも遅い速度で進むようなモードである。或る形態のスロー順送りは、図７及び図８を参照して前述した技術により既に可能である。高速順送り速度をゼロと１との間の値に設定する結果、高速順送りトリックプレイＧＯＰの繰り返しに基づくスロー順送りストリームが得られる。平文ストリームにとり、これは適切な解決策であるが、暗号化されたストリームの場合、これは或る特定の条件ではＩフレームの一部の誤った解読につながり得る。この問題を解決する１つのオプションは、前記高速順送りトリックプレイＧＯＰを繰り返さないで、該トリックプレイＧＯＰのサイズを空のＰフレームの追加により延長することである。この技術は、事実、スロー逆送りをも可能にし得る。何故なら、これは、高速順送り／逆送りに使用されるトリックプレイＧＯＰに、従って独立に復号可能なＩフレームに基づくからである。
【０１５８】
このようなＩフレームに基づくスロー順送り又はスロー逆送りは、下記の理由により特別な場合には不適であり得る。通常プレイにおけるＩフレーム間の距離は約半秒であり、スロー順送り／逆送りの場合、該距離はスローモーション係数により乗算される。従って、このタイプのスロー順送り又はスロー逆送りは、正確にはスローモーションとして通常理解されているものではなく、実際には連続する画像の間に大きな時間的距離を伴うスライドショーのようなものである。
【０１５９】
静止画モードでは、表示画像は停止され得る。これは、静止画モードの期間にわたりＩフレームに空のＰフレームを追加することにより達成することができる。これは、最後のＩフレームからの画像が停止されることを意味する。通常プレイから静止画像に切り換える場合、これも、ＣＰＩファイル内のデータによる最も近いＩフレームであり得る。この技術は、高速順送り／逆送りモードの拡張であり、特にインターレース相殺が使用される場合、良好な静止画像が得られる。しかしながら、通常プレイ又はスロー順送り／逆送りから静止画へ切り換える場合、位置精度は常に満足のゆくものとは限らない。
【０１６０】
上記静止画モードは、ステップモードを実施するために拡張することができる。ステップコマンドは、当該ストリームを何れかの次の又は前のＩフレームに進める。ステップのサイズは、最小で１ＧＯＰであるが、整数の数のＧＯＰに等しい大きな値に設定することもできる。この場合、Ｉフレームのみが使用されるので、ステップ順送り及びステップ逆送りの両方が可能である。
【０１６１】
スロー順送りストリームの構築に対しては、多くの考慮事項がある。例えば、基本ストリームレベルでのスロー順送りストリームの構築は、完全に平文のデータに対してのみ実行することができる。結果として、通常プレイストリームが元々暗号化されていたとしても、スロー順送りストリームは完全に平文であろう。このような状況は、著作権保持者にとり許容不可能であり得る。更に、これは高速順送り／逆送りストリームの場合におけるよりも悪い。何故なら、真の高速順送り／逆送りストリームの場合におけるようにフレームの部分集合だけでなく、全ての情報（即ち、各々の及び全てのフレーム）が、当該スロー順送りストリーム内に平文で存在するからである。従って、平文のスロー順送りストリームから平文の通常プレイストリームを容易に再構築することができる。従って、通常プレイストリームが暗号化されているなら、該スロー順送りストリームも暗号化されるべきである。ＤＶＢ暗号器は家電装置では許可されないので、これは、スロー順送りストリームが、元々送信された暗号化されたデータストリームの暗号化されたデータパケットを用いてトランスポートストリームレベルで構築される場合にのみ実現することができる。
【０１６２】
以下においては、図１８ないし図６３を参照して、本発明の実施例によるシステムにおいてデータストリームを処理することができるようなシステムを説明する。
【０１６３】
以下で述べるシステムは、図１ないし図１７を参照して説明したシステムの何れかの枠内で且つ斯かるシステムの何れかとの組み合わせで実施化することができることを強調しておく。
【０１６４】
以下、図１８ないし図２２を参照して、本発明の実施例によるデータストリームを処理する方法を説明する。
【０１６５】
図１８は、完全に暗号化されたＭＰＥＧ２データストリーム１８００を示し、該ストリームは安全保護の理由でデータソースから再生装置への移行の間に完全に暗号化されるようなデータストリームである。
【０１６６】
暗号化されたデータストリーム１８００に関するメディアコンテンツのスローモーション再生であるスロー順送りトリックプレイモードを提供するために、以下に詳細に説明するような種々の操作ステップを実行することができる。
【０１６７】
第１ステップとして、図１９に示されるように、上記の完全に暗号化されたＭＰＥＧ２データストリーム１８００は、部分的に解読されると共に部分的に暗号化されたハイブリッドデータストリーム１９００を形成するように処理される。該ハイブリッドデータストリーム１９００は、当該暗号化されたデータストリーム１８００における隣接する暗号化されたフレーム１９０２の間の暗号化されたフレーム境界部分１９０１を、対応する解読されたフレーム境界部分１９０１により選択的に置換して、部分的に解読されると共に部分的に暗号化されたハイブリッドデータストリーム１９００を形成することにより得ることができる。更に詳細には、解読されたフレーム境界部分１９０１の一部は、画像開始コード部１９０３により形成される。フレーム境界部分１９０１は、個々に解読することが可能な最小の部分とすることができ、該部分の一部は（所望の）画像開始コード部１９０３である。この処理は、当該ビデオコンテンツの連続するフレームの間の画像開始コード１９０３を（完全に又は部分的に）含むパケット１９０１が平文になる（即ち、部分１９０１が解読されたものとなる）一方、当該データストリーム１９００の残りの（多くの場合、主たる）部分、即ち実際のオーディオ又はビデオコンテンツ１９０２が暗号化されたままとなるように実行することができる。しかしながら、画像開始コード１９０３は、以下で説明するように、トリックプレイ動作を可能にすべく復号された態様で存在する。
【０１６８】
図２０からわかるように、ハイブリッドデータストリーム１９００は、該ハイブリッドデータストリーム１９００の隣接するフレーム１９０２をフレーム境界部分１９０１／画像開始コード部１９０３において分割することにより更に処理される。言い換えると、順次の連続的ハイブリッドデータストリーム１９００は、対応するフレーム境界部分１９０１及び対応するフレーム１９０２を含むような別々の部分に分離される。
【０１６９】
更に、図２１から分かるように、分離されたフレーム２０００の幾つか、即ちＢフレームは、所定のスロー順送り率に従って複数回（本実施例では３回）繰り返される。アンカフレーム（Ｉフレーム及びＰフレーム）は、空フレーム２００１を用いて繰り返される。本例では、スロー順送り率は、３なる係数である。これは、暗号化されたデータストリーム１８００のビデオコンテンツが、当該スロー順送りモードにおいて、通常プレイ動作モードと比較して１／３の速度で再生されるべきことを意味する。
【０１７０】
トリックプレイストリームを得るために、（空のフレームを挿入する代わりに）アンカフレームを複数回繰り返すことも可能であると言える。個々の部分的に暗号化され且つ部分的に解読された部分２０００を複数回繰り返すと共に、次いで、複製された分割フレーム２０００を互いに接続することにより、画像開始コード１９０１及びフレーム１９０２の異なるグループから得られる隣接する部分が、互いに適切な形で合致しなくなってしまう。このため、これらの部分は、図２２に示すようにトリックプレイに適したハイブリッドデータストリーム２２０１が得られるように、所望なら、接続部分２２００を選択的に修正することにより結合される。
【０１７１】
以下においては、図２３を参照して本発明の一実施例による処理装置２３００を説明する。
【０１７２】
該処理装置２３００により、図１８ないし図２２を参照して説明した種々の方法のステップを実行することができる。
【０１７３】
図２３は、暗号化された再生されるべきオーディオビジュアルコンテンツが記憶されたハードディスク２３０１を示している。
【０１７４】
当該処理装置２３００は、中央処理ユニット（ＣＰＵ）２３０２等の制御ユニットにより制御することができ、斯かるＣＰＵはユーザインターフェース２３０３を用いてユーザにより制御することができる。ユーザインターフェース２３０３により、ユーザは当該処理装置２３００の動作を制御することができ、例えば通常プレイモード又はスロー順送りモード等のトリックプレイ動作を開始させることができる。
【０１７５】
対応する制御信号が中央処理ユニット２３０２からハードディスク２３０１に送られると、暗号化された形態のオーディオビジュアルコンテンツが該ハードディスク２３０１から解読器２３０４に送られる。解読器２３０４は、暗号化されたデータストリーム１８００における隣接するフレーム１９０２の間の暗号化されたフレーム境界部分を、解読されたフレーム境界部分１９０１により選択的に置換して、部分的に解読されたデータストリーム１９００を発生するように構成されている。
【０１７６】
部分的に解読されたデータストリーム１９００は、該部分的に解読されたデータストリーム１９００の隣接するフレーム１９０２をフレーム境界部分１９０１で分割する分割ユニット２３０５に供給される。分割されたハイブリッドストリーム部分２０００のシーケンスは、所定の複製率に従って該分割フレーム２０００を複数回（図１８〜２２の例では、３回）複製する複製ユニット２３０６に供給されるが、該所定の複製率はマイクロプロセッサ２３０２により及び／又はユーザインターフェース２３０３を操作するユーザにより規定又は決定することができる。
【０１７７】
図２１に示した個々の部分は、次いで、複製ユニット２３０６から接着ユニット又は接続ユニット２３０７に供給することができ、該接続ユニットは図２１の複製された分割フレームを接続して、トリックプレイが可能なストリーム２２０１を発生する。
【０１７８】
このストリームは、スピーカを備えるモニタ等の再生ユニット２３０８に供給することができ、該ユニットにおいては、このコンテンツの再生がマイクロプロセッサ２３０２の制御の下で及び／又はユーザインターフェース２３０３を介してのユーザの制御の下で可能となる。
【０１７９】
暗号化されたデータストリーム２２０１を再生のために解読すべく、再生ユニット２３０８内の更なる解読ユニット（図示略）を予見することも可能である。
【０１８０】
前記解読ユニット２３０４は、暗号化されたデータストリーム１８００における隣接するフレーム１９０２間の暗号化されたフレーム境界部分のみを、フレーム境界部分１９０１を含む解読されたパケットにより選択的に置換し、全ての他のフレーム部分１９０２は暗号化されたままに維持する。これは高度の安全保護を保証する。何故なら、トリックプレイストリーム２２０１を発生するために平文でなければならない選択された部分のみしか解読されていないからである。
【０１８１】
後に詳細に説明するように、分割ユニット２３０５は２つの連続するフレームのデータを含み得る平文パケットを、各々が斯かるフレームの一方からのデータのみを含むような２つのパケットに変換し、これらパケットの各々に詰め物をすることができる。接着ユニット２３０７は、図２１の複製された分割フレームを、フレーム境界部分１９０１が２つのフレーム１９０２の間に延びている位置２２００を識別することに基づいて、及び斯かる識別された位置を補正することに基づいて接続することができる。
【０１８２】
このような補正は、フレーム境界部分１９０１のサイズの部分を決定することを含むことができる。該サイズが大きすぎる場合、短縮することができ、該サイズが小さい場合は、長さを増加させることができる。
【０１８３】
フレーム１９０２は、イントラ符号化フレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）又は双方向予測フレーム（Ｂフレーム）とすることができる。処理されるコンテンツ１８００はビデオデータ及び／又はオーディオデータのデータストリームとすることができる。再生ユニット２３０８は、接続ユニット２３０７に接続されたデータストリームを再生することができる。暗号化されたデータストリーム１８００は、暗号化されたＭＰＥＧ２データストリームとすることができる。
【０１８４】
以下においては、図２４を参照して、本発明の他の実施例によるデータ処理装置２４００を説明する。
【０１８５】
データ処理装置２４００は前記データ処理装置２３００とは、図２４の場合に解読ユニット２３０４が予定されていない点で異なる。この場合、ハイブリッドデータストリーム１９００が、ハードディスク２３０１から直接供給される。これは、解読ユニット２３０４がハードディスク２３０１内に統合されているか、又はデータがハードディスク２３０１に既に図１９に示すような態様で記憶されているかの何れかを意味する。
【０１８６】
以下においては、本発明の実施例によるスロー順送りトリックプレイ再生に関する更なる詳細を説明する。
【０１８７】
次に、ストリームの別個のフレームへの分割を説明する。
【０１８８】
トランスポートレベルでスロー順送りストリームを構築するのを可能にするためには、個々のフレームが一連のトランスポートストリームパケットとして利用可能であることが有利である。フレーム当たり１ＰＥＳパケットの場合、これは当然に生じる。ＰＥＳ及びトランスポートストリームパケットは整列されているので、ＰＥＳパケットは一連のトランスポートストリームパケットに含まれる。ＧＯＰ当たり１ＰＥＳパケットの場合、これはＩフレームの開始にだけ当てはまる。全ての他のフレーム境界は、殆どの場合、パケット内の何処かに位置される。このパケットは、当該２つのフレームからの情報を含む。従って、先ず、このパケットを２つのパケットに分割することができ、最初のものは最初のフレームからのデータを含み、第２のものは次のフレームからのデータとなる。上記分割の結果の斯かる２つのパケットの各々は、アダプテーションフィールド（ＡＦ）により詰めることができる。
【０１８９】
この状況が図２５に示されている。
【０１９０】
図２５は、フレーム境界でのパケットの分割を示す。特に、図２５は、各々がヘッダ２５０１とフレーム部分２５０２とを有する複数のＴＳパケット２５００を示す。図２５に示されたデータストリームの中央部分から分かるように、ヘッダ２５０１と２つの連続するフレーム２５０２とを有するパケットが、各々が別個のヘッダ２５０１と、後続するアダプテーションフィールド２５０３と、後続する対応するフレーム２５０２とを有するような２つの別個の部分に分割される。
【０１９１】
パケットの分割は、平文のストリームにとっては困難ではない。第１のオプションは、図２６に示されるように、通常プレイのデータを完全に解読することである。図２６は、通常プレイデータの解読の後のスロー順送りの構築を示す。ハードディスク２６０１からの暗号化された通常プレイのデータ２６００は、平文ストリーム２６０３を発生する解読器２６０２に供給される。該平文ストリーム２６０３は、異なるフレームを図２５に示した態様で分割するためのフレーム分割ユニット２６０４に供給される。次いで、このデータは、スロー順送りストリームを構築するスロー順送り構築ユニット２６０５に供給され、該スロー順送りストリームは次いでセットトップボックス２６０６に供給される。
【０１９２】
記憶された完全に暗号化されたストリーム２６００又は記憶されたハイブリッドストリームの解読及びスロー順送りモードは困難ではない。何故なら、解読器２６０２により当該ストリームにおいてストリームデータがスキップ又は複製されることはないからである。記憶されたストリーム２６００（完全に暗号化された又はハイブリッドの）は、解読器２６０２を介して単に通常より遅いレートで供給され、これは、埋め込まれたＥＣＭ（エンタイトルメント制御メッセージ）にとり何の問題もないことも意味する。この場合、解読器ユニット２６０２から到来する平文ストリーム２６０３はパケットを分割するために、又は実際にフレーム分割ユニット２６０４における如何なる必要なストリーム操作を実行するためにも使用することができる。この場合、結果としてのスロー順送りストリームは平文ストリームである。
【０１９３】
暗号化された通常プレイストリームからの暗号化されたスロー順送りストリームの構築は、トランスポートレベルで実行される。何故なら、家電装置でのＤＶＢ（デジタルビデオ放送）暗号器の使用は特別な場合に許可されないからである。このため、全てのフレーム境界上に僅かの平文パケット２７００及び２７０２のみを伴うハイブリッドストリーム（図２７参照）が必要となる。図２７は、更に、Ｉフレーム２７０３、Ｂフレーム２７０４又はＰフレーム２７０５に属する暗号化されたパケット２７０１も示している。
【０１９４】
以下、記憶されたストリームが完全に暗号化されている場合、上記のようなストリームを記憶装置の再生側でどの様に発生することができるかを説明する。この場合、図２６の解読器ユニット２６０２は、必要なパケットのみを解読するような選択型とすることができる。しかしながら、好ましくは、当該ストリームは図２８に示すように既にハイブリッドストリームとして記憶されているものとする。
【０１９５】
図２８は、記憶されたハイブリッドストリーム２８００に対するスロー順送りの構築を示す。図２８に示す配列において、ハードディスク２６０１とフレーム分割ユニット２６０４との間には解読器ユニット２６０２は予定されていない。しかしながら、この場合に、セットトップボックス２６０２に解読器ユニット２８０１を予定することができる。
【０１９６】
この場合、上記ハイブリッドストリームにおける平文パケット２７００、２７０２は２つのフレームからのデータを含むパケットの分割も可能にしなければならない。これは、後に詳細に述べる規準により保証することができる。しかしながら、シーケンスヘッダコード又は画像開始コードの何らかの部分が、依然として、暗号化されたパケット内に位置する可能性がある。この場合、理想的な分割は容易には可能ではない。事実、分割は暗号化されたパケットと平文パケットとの間でなされ得る。これらの問題に対する解決策を、以下に更に詳細に説明する。その状況においては、空のＰフレームのみがＩフレームに連結されるか又はその逆とする。フレームに基づくスロー順送りの場合、他のタイプの連結も考えることができ、それらの中にはＢフレームのＢフレームに対する連結もある。その結果は、図２９を参照して明確にされるように、これらのフレーム境界における或る種の接着アルゴリズムとなる。
【０１９７】
図２９はデータストリームを示し、前のフレーム２９００、現フレーム２９１２及び次のフレーム２９０１が示されている。前のフレーム２９００の終了部には、３バイトの画像開始コード２９０２が設けられる。更に、現フレーム２９１２の開始部には、１バイトの画像開始コード２９０３が予定される。ここで、次のフレームに来ると、当該パケットのフレーム終了部が、前に、１バイトの画像開始コード２９０４を有する。次のフレーム２９０１の開始部には、３バイトの画像開始コード２９０５が設けられる。図２９は、連結点に不完全な画像開始コードが存在し得ることを示している。これが、接続領域２９０６において接着を必要とさせ得る。このように、接着は、Ｂフレーム２９０７とＢフレームの繰り返し２９０８との間で実行されるべきである。
【０１９８】
図２９は、パケットヘッダ２９０９、平文データ２９１０及び暗号化されたデータ２９１１を特に示している。図２９の例では、Ｂフレームの開始部及び終了部に１バイトのみの画像開始コードが存在する。結果的に、連結点では２バイトが失われている。後に詳述する接着アルゴリズムは、このような問題を直すことができる。この接着のためには、画像開始コードがどの様に分割されるかが知られねばならない。この情報は後に詳述する方法により得ることができる。
【０１９９】
以下においては、フレームの繰り返しを詳細に説明する。
【０２００】
スロー順送りモードにおいては、デコーダは、何とかして、画像の表示をスロー順送り係数に従って繰り返すように強制されなければならない。Ｉフレームからの結果の画像の繰り返しを強制するために、空のＰフレームを使用することができる。この技術は、Ｐフレームからの結果の画像にも適用することができる。しかしながら、この技術はＢフレームには容易に適用することができない。何故なら、空のＰフレームは、常にＩフレーム又はＰフレームであるアンカフレームを指すからである。これは、実際に、如何なる空のフレームにも当てはまる。従って、Ｂフレームから得られた画像の繰り返しは他の方法で実現されなければならない。可能性のある方法は、Ｂフレームデータ自体を繰り返すことである。繰り返されるＢフレームは元のＢフレームと同一のアンカフレームを指すので、結果として得られる画像も同一となるであろう。Ｂフレームに対するデータの量は、空のＰフレームに対するよりは通常は大幅に多いが、それでも一般的には、Ｉフレームに対するよりは著しく少ない。いずれにせよ、伝送もスローモーション係数により乗算されるので、少なくとも平均ではビットレートの増加は必要でない。
【０２０１】
Ｉフレーム又はＰフレームからの画像の繰り返しを強制するために使用される空フレームは、インターレース打消型のものとすることができ、かくして、これら画像に対するインターレースアーチファクトを低減する。しかしながら、斯様な低減はＢフレームからの画像に対しては容易に可能ではない。何故なら、繰り返しが空フレームによって強制されるのではなく、Ｂフレームデータ自体の繰り返しによるからである。従って、これらＢフレームは元のインターレース効果を有するであろう。インターレース打消がＩフレーム及びＰフレームに対して使用されたとしたら、これは非常にぎこちなく見える。何故なら、インターレース効果を伴う及び伴わない画像が、表示される画像のストリームに順に現れるからである。現在のところ、スロー順送りストリームを構築するにはインターレース打消を伴わない空フレームのみを使用する方がよいと信じられる。
【０２０２】
Ｉフレーム及びＰフレームの繰り返しは、伝送ストリーム内に、元のＩフレーム又はＰフレームの後に空のＰフレームを挿入することにより実行することができる。このような方法は、空のＰフレームにより後続されたＩフレームを有する高速順送り／逆送りストリームに対して使用することができる。しかしながら、この方法は、Ｂストリームを伴う記憶された伝送ストリームから構築されるスロー順送りストリームの場合におけるように、Ｂフレームも含むストリームに対しては絶対的に正しいものではない。伝送データから表示ストリームへの再配列により、Ｉフレーム及びＰフレームが誤った位置で繰り返され、これによりフレームの通常の表示順序を妨げるであろう。これが、図３０及び図３１に示されている。
【０２０３】
図３０は、通常プレイにおける再配列の効果を示している。図３０は、伝送順序３０００及び表示順序３００１を示している。特に、図３０は通常プレイにおける再配列の効果を示している。上側のラインは、Ｉフレーム２７０３、Ｐフレーム２７０５及びＢフレーム２７０４を有する１２フレームのＧＯＰサイズの通常プレイ伝送（transition）ストリームを示す。明瞭化のために、次の伝送ＧＯＰの最初の４つのフレームも示されている。図３０の下側のラインは、表示順序への再配列後のストリーム３００１を示している。インデックスは表示フレーム順序を示している。ＭＰＥＧ２規格ＩＳＯ／ＩＥＣ13818-2:1995(E)（特に、第２４及び２５頁参照）によれば、再配列は下記のように実行することができる：
− Ｂフレームは元の位置を維持する；
− アンカフレーム（即ち、Ｉフレーム及びＰフレーム）は次のアンカフレームの位置にシフトされる。
【０２０４】
図３１は、スロー順送りモードにおける再配列の効果を示す。特に、図３１は、伝送順序３１００、再配列後の順序３１０１及び表示される画像の順序３１０２を示す。通常プレイストリームから構築されるスロー順送りストリームをより詳細に調べると、図３１の一番上のラインは、この場合のスローモーションストリームの最初の部分の伝送順序３１００を示し、３なるスローモーション係数を仮定している。空のＰフレームをＩフレーム及びＰフレームの後に挿入することができ、Ｂフレームは繰り返すことができる。図３１の真ん中のラインは再配列の効果を示している。図３１の一番下のラインは、この場合に、空のＰフレームによりＩフレーム及びＰフレームがどの様に繰り返されるかを示している。空のＰフレームは、前のアンカフレームからの結果の画像のコピーであるような表示画像となり、該前のアンカフレーム自体も空のＰフレームであり得る。図３１では、インデックスにより示される通常表示順序３１０２が、フレームＩ４の表示が２つの部分に分割される故に妨害されることがわかる。最後のフレームＩ４だけが正しい位置に表示される。これは、Ｂフレームが誤って復号され得ることも意味する。
【０２０５】
以下においては、上記のような欠陥を如何にして補正するかの幾つかのオプションを説明する。１つの可能性が図３２に示される。図３２はアンカフレームの前に空のＰフレームを挿入するものを示す。図３２における３つの行は、図３１における３つのラインと同様である。図３２において、一番上のライン３１００に示すように、空のＰフレームは、記憶装置から抽出された伝送ストリームにおけるアンカフレームの前に挿入される。再配列されたストリーム３１０１では、空のＰフレームはアンカフレームの後に配置される。これは、図３２の表示画像３１０２から明らかなように、アンカフレームの正しい繰り返しのためにあるべき位置である。
【０２０６】
しかしながら、空のＰフレームを回避することが何故適切であり得るかの意見が存在する。１つは、ＧＯＰ内でのエラーの増殖に関するものである。Ｐフレームは前のアンカフレームに依存し、Ｂフレームは周りのアンカフレームに依存する。セットトップボックスへの伝送の間のデータエラーは符号化エラーとなり、従って画像における乱れとなる。このエラーがアンカフレームであると、該エラーはＧＯＰの終わりまで伝搬する。何故なら、後続のＰフレームは、このアンカフレームに依存するからである。また、Ｂフレームの影響を受ける。何故なら、これらＢフレームは、復号のために、妨害された周囲のアンカフレームからの画像を使用するからである。これは、画像の乱れがＧＯＰの終わりに向かって徐々に増加するという結果を有し得る。これは、ＧＯＰサイズが非常に大きく、従って時間的に非常に長くなり得るようなスロー順送りの場合に特に重要であり得る。一方、Ｂフレームにおけるデータエラーは非常に限られた影響しか有さない。何故なら、Ｂフレームには他のフレームは依存しないからである。従って、画像の乱れは当該Ｂフレーム及びその繰り返しに限られる。デジタルインターフェースではデータエラーは生ぜず、空のＰフレームの使用を回避することには第２の利点が存在し得るとの意見があり得る。もし、これらがインターレース打消型のものである場合、これらは当然復号された画像においても変化し、結果として後続のフレームにとっても復号エラーとなる。従って、インターレース打消は不可能であろう。
【０２０７】
空フレームの構築を考えると、幾つかのタイプの空Ｂフレームを構築することができる。これらは、付加的なエラー増殖が生ぜず、インターレース打消を使用することができるという利点を有し得る。
【０２０８】
可能性のあるタイプの空Ｂフレームは、順方向予測空Ｂフレーム（Ｂｆフレームと称する）及び逆方向予測空Ｂフレーム（Ｂｂフレームと称する）である。
【０２０９】
Ｂフレームは、通常、双方向予測的であるが、単方向予測Ｂフレームも存在し得る。後者の場合、これら単方向予測Ｂフレームは順方向予測的又は逆方向予測的であり得る。順方向予測的とは、符号化の間においてアンカフレームが後続のＢフレームを予測するために使用されることを意味する。従って、順方向予測Ｂフレームからの結果としての画像は、復号の間に前のアンカフレームから再構築される。これは、Ｂｆフレームが前のアンカフレームの繰り返しを強制することを意味する。従って、これは、空Ｐフレーム又はＰｅフレームと同一の効果を有する。Ｂｂフレームは反対の効果を有する。該フレームは、自身に後続するアンカフレームの表示を強制する。両タイプのＢフレームに対して、インターレース打消バージョンも可能である。
【０２１０】
以下においては、このような空Ｂフレームを、スロー順送りストリームの構築のためにどの様に使用するかを説明する。
【０２１１】
Ｂｂフレームに基づく第１の可能性が図３３に示されている。
【０２１２】
Ｂｂフレームは、アンカフレームの前に挿入され、再配列の間において自身の位置を維持する。アンカフレームは、次のアンカフレームの位置にシフトされる。該Ｂｂフレームは、再配列されたストリームにおいて自身に後続するアンカフレームの表示を強制する。
【０２１３】
他のオプションは、図３４に示されるように、Ｂｆフレームの使用である。
【０２１４】
Ｂｆフレームは、伝送ストリームにおけるアンカフレームの後に挿入される。再配列されたストリームにおけるアンカフレームの繰り返し表示が、斯かるアンカフレームに後続するＢｆフレームにより強制される。
【０２１５】
Ｂｆフレームの使用は、高速順送り及び高速逆送りストリームの構築のための空Ｐフレームの使用に類似している。事実、その場合にはＢｆフレームの使用も可能であり、かくして、トリックプレイの発生を更に一層共通化させる。しかしながら、Ｂｆフレームが高速順送り及び高速逆送りのために使用される場合、再配列の効果が考慮されねばならない。これは、ＰＴＳ／ＤＴＳ及び時間基準等の高速順送り／逆送りストリームにおける幾つかのパラメータが適切に選択されなければならないことを意味する。
【０２１６】
次に、個々のフレームの接着を説明する。
【０２１７】
特に、不完全な画像開始コードの場合におけるフレームの接着を説明する。スロー順送りストリーム内の連結点における所要の接着動作を決定するためには、先ず、元のストリームが何処で個々のフレームに明確に分割されるが明らかでなければならない。以下においては、ＧＯＰ当たり又はフレーム当たり１個のＰＥＳパケットの実際的状況を考察する。
【０２１８】
フレーム当たり１つのＰＥＳパケットの場合、元のストリームは図３５に示されるように、PLUSIを伴うパケットと先行するパケットとの間で分割することができる。
【０２１９】
図３５には、フレーム当たり１つのＰＥＳパケットの場合のストリームの分割が示されている。図３５に示されるデータストリームは、平文パケットヘッダ３５００、アダプテーションフィールド３５０１、平文データ３５０２、暗号化されたデータ３５０３及び平文ＰＥＳヘッダ３５０４を含んでいる。更に、PLUSIプレゼントは符号３５０５により示され、ＰＥＳヘッダは符号３５０６により示される。
【０２２０】
個々のフレームは、複数の完全な元のパケットを有する。従って、パケットの分割は必要ではない。このフレーム分割は完全に暗号化されたストリームにおいても実行することができるが、スロー順送りストリームの構築には何らかの平文データへのアクセスが依然として必要である。PLUSIを伴うパケットの開始部における分割は、２つのパケットにわたって広げられた画像開始コードは存在しないことも意味する。個々のフレームは、自身の正しく且つ完全な画像開始コードを含む。従って、この場合は、接着動作は必要ではない。
【０２２１】
しかしながら、ＧＯＰ当たり１つのＰＥＳパケットの場合、状況は異なる。ＰＥＳヘッダが先行しない限り、フレーム間の分割は新たなフレームの画像開始コードにおいてなされる。
【０２２２】
分割点を決定するために下記のアルゴリズムを使用することができる：
１．元のストリームは、PLUSIビット組、画像開始コード及び画像コーティング拡張部を伴うパケットに関して同時に調査される；
２．PLUSIビット組を伴うパケットが最初に遭遇された場合は、このパケットの開始部で分割がなされる（画像開始コード３６００及び画像コーティング拡張部３６０１を含み、図３６を参照されたい）。次いで、当該ストリームは、画像コーティング拡張部をサーチされる。これが見つかった後、当該サーチはポイント１で説明したように継続される；
３．画像開始コードが最初に遭遇された場合は、分割は該画像開始コードの開始部においてなされる。多くの場合、これは、当該画像開始コードを含むパケットは２つのパケットに分割されねばならず、これらのうちの最初のものは前のフレームに割り当てられ、第２のものは後続のフレームに割り当てられることを意味する（画像開始コード３６００の開始部におけるストリームの分割を示す図３７を参照されたい。この場合、アダプテーションフィールドの挿入箇所は符号３７００で示されている）。両パケットはアダプテーションフィールド３７００により詰められる。この場合、第２のパケットのペイロードは画像開始コード３６００で開始する。元のパケットの記録タイムスタンプは、当該分割の結果としての２つのパケットの各々にコピーされる。２つのフレームの連結点において分割からの２つのパケットが使用されるか又は元のパケットが使用されるかは、後述するように特定の状況に依存する。次いで、当該ストリームは画像コーティング拡張部をサーチされる。これを見つけた後、当該サーチはポイント１で説明したように継続される；
４．画像コーティング拡張部が最初に遭遇された場合、画像開始コードは検出不可能に違いない。何故なら、これは部分的に暗号化されているからである。これは、現平文領域が画像開始コードの幾つかのバイトで開始することを意味する。この場合、分割は現平文領域の最初の平文パケットの開始部でなされる（画像開始コード３６００内での当該ストリームの分割を示す図３８を参照されたい。該図は画像開始コードのバイト３８００及び画像コーティング拡張部３６０１も示す）。ポイント１で説明したサーチは、画像コーティング拡張部３６０１を見つけた後に継続される。
【０２２３】
上述したアルゴリズムの結果、フレーム当たり１つのＰＥＳパケットを持つストリームに関する正しい分割点も得られるであろう。更に、該アルゴリズムは、平文ストリーム及び前述したハイブリッドストリームに対する適用のためにも設計されている。
【０２２４】
接着は、前記アルゴリズムのポイント４からのみ生じ得るような不完全な画像開始コードの場合においてのみ必要である。従って、ポイント４のみが、非理想的な分割点となる。平文ストリームは理想的な分割点のみを有する。何故なら、画像開始コードが常に見つかるからである。従って、この場合、接着は必要でない。しかしながら、ハイブリッドストリームは非理想的な分割点を含むであろう。以下に述べる方法は、当該画像開始コードのうちのどれだけ多くのバイトが非理想的分割点の何れの側にあるかを決定するために使用することができる。非理想的分割点の効果は、後に詳細に説明する。
【０２２５】
次に、何れかのタイプの空Ｐフレームが斯様な非理想的分割点に挿入されるような状況を考察する。最初の空のフレームを如何に扱うかを以下に説明する。分割点の後の画像開始コードの部分に等しい複数のバイトが、最初の空フレームの画像開始コードから削除される。中間の空フレームは変更されない。最後の空フレームは、後続のフレームの画像開始コードの欠けている部分のために補正されなければならない。従って、この欠けている部分は最後の空フレームの終了部に追加することができる。理想的分割点で挿入された空フレームに対し変更は必要ない。
【０２２６】
以下においては、Ｂフレームの繰り返しを考察する。Ｂフレームが両側に理想的分割点を有する場合、繰り返しのために如何なる接着動作も必要でない。しかしながら、当該フレームの何れかの側に非理想的分割点が存在すると、接着動作が必要となるか又は有利となり得る。元のフレーム及びその繰り返しが、同一のＢフレームの系列を形成する。該系列の開始部及び終了部では接着動作は必要でない。何故なら、ここでは、フレームは通常プレイストリームにおけるように同じフレームに接続されるか、又は空フレームに接続されるかの何れかであるからである。最初の場合では、不連続部は存在しない。何故なら、当該データの通常の順序が、この位置で回復されるからである。２番目の場合に対する解決策は、先に示した。従って、Ｂフレームの終了部が同じＢフレームの開始部に接続されるような中間の連結点のみが考察されねばならない。ここで述べる例は、図２９を参照して前述した例であり、明瞭化のために図３９において一層詳細に繰り返し説明する。
【０２２７】
図３９は、連結点における不完全な画像開始コードを示す。
【０２２８】
正しい接着のためには、Ｂフレームの終了部及び開始部における画像開始コード（ＭＰＥＧ２内では、開始コードは長さが４バイトであり得る）のバイト数を知る必要がある。終了部におけるバイト数をｎにより、開始部におけるバイト数をｍにより表すと、理想的分割の場合、ｎ＝０及びｍ＝４である。非理想的分割点の場合、或るフレームに対する数ｎ及び後続のフレームに対する数ｍは、以下に示すような方法により決定することができる。
【０２２９】
ｎは決して４に等しくはならないことは明である。何故なら、その場合、分割は画像開始コードの開始点においてなされたことになり、結果としてｎ＝０となるからである。一方、ｍは決して０ではあり得ない。何故なら、その場合、画像開始コードは完全に前のフレーム内となり、分割は理想的位置でなされたことになり、かくして、ｍ＝４となるからである。従って、０≦ｎ≦３及び１≦ｍ≦４が通常の状況である。
【０２３０】
或る同一のフレームＮに対して数ｎ及びｍを得るために、これら数は、当該フレームの周囲の２つの分割点の情報から抽出されねばならない。かくして、ｎ及びｍは、繰り返されるべきＢフレームの終了部及び開始部における画像開始コードのバイト数を表す。結果として、これらは、中間の連結点の前及び後の画像開始コードの複数のバイトも表すことになる。
【０２３１】
次に、ｎ＋ｍ＝４と仮定する。これは、当該Ｂフレームを囲む両分割点が理想的である場合である。しかし、その場合には接着動作が必要とされないことが既に分かっている。しかしながら、これは両分割点が非理想的である場合でもあり得る。これは、図４０に示された状況である。
【０２３２】
図４０は、従って、ｎ＋ｍ＝４なる例を示している。
【０２３３】
フレームＮの最後のパケットが符号４０００で示され、図４０は、更に、符号４００１により示されたフレームＮの最初のパケットも示す。境界４００２では、接着動作は必要ではない。画像開始コードのバイト（ｎ＝３）が符号４００３により示され、画像開始コードのバイト（ｍ＝１）が符号４００４により示されている。
【０２３４】
ｎ＋ｍ＝４なる事実は、正しい量の画像開始コードバイトが連結点に存在し、接着動作は必要ないことを意味する。
【０２３５】
しかしながら、図４１はｎ＋ｍ＞４の状況を示している。
【０２３６】
これは、連結点に１、２又は３バイト過剰に存在することを意味する。この場合、ｎ＋ｍ−４に等しい数のバイトが第２フレームの開始部から削除される。これは、これら平文バイトを、詰め込みバイトを含むアダプテーションフィールド（ＡＦ）により置換することにより達成される。アダプテーションフィールドが既に存在する場合、その長さがｍ＋ｎ−４だけ増加されねばならず、破棄されるべきデータは、規格によれば１６進数のＦＦを有する詰めバイトにより置換される。
【０２３７】
ｎ＋ｍ＞４及びｎ＜３なる特別なケースでは、接着を行わないことも可能である。実効的に、基本ストリーム詰め込みを得る。
【０２３８】
接着動作が必要な箇所は、符号４１００により示される。本例において、画像開始コードのバイト（ｎ＝２）は符号４１０１により示されている。画像開始コードのバイト（ｍ＝３）は符号４１０２により示されている。更に、画像開始コードのバイト（ｎ＝２）は符号４１０３により示され、画像開始コードのバイト（ｍ＝２）は符号４１０４により示されている。アダプテーションフィールドを用いて置換されたバイトの位置は、符号４１０５により示されている。
【０２３９】
図４２を参照すると、ｎ＋ｍ＜４と仮定されている。
【０２４０】
これは、連結点における画像開始コードから１、２又は３バイトが不足していることを意味する。この場合、何のバイト又は複数のバイトがないかを知る必要がある。ｎ及びｍは両方ともわかるので、不足しているバイトは固有に識別することができる。かくして、不足バイトは新たなパケットに配置され、該パケットは更にアダプテーションフィールドにより詰められる。この接着パケットは、次いで、上記２つのフレームの間に配置される。この接着パケットは、符号４２００により示されている。符号４２０１は画像開始コードのバイト（ｎ＝２）を示し、符号４２０２は画像開始コードのバイト（ｍ＝１）を示す。また、符号４２０４は挿入されたバイト（４−ｎ−ｍ）を示す。また、符号４２０５は画像開始コードのバイト（ｍ＝１）を示す。
【０２４１】
以下においては、タイムスタンプを用いたフレーム及びパケットの位置決めを説明する。
【０２４２】
この説明は、各パケットに予め添付された記録タイムスタンプを用いた、フレーム及びパケットのスロー順送りストリームの時間軸上への配置を扱う。説明は、元の通常プレイフレームの配置で開始する。次いで、Ｂフレームの繰り返し及び圧縮が説明される。続いて、空フレームの配置が説明される。最後に、ＰＣＲに関する幾つかの問題が議論される。
【０２４３】
次に、元の通常プレイフレームの位置決めを説明する。
【０２４４】
必要なデータが受信される前に復号が開始すると、復号問題が発生し得る。このような可能性のある復号問題は、スロー順送りストリームの場合、フレームデータの終わりから、このフレームのＤＴＳまでの距離がスロー順送りストリーム及び通常プレイストリームに対して同一であるなら回避することができる。これは、対応するＤＴＳの当該フレームデータの開始における距離を通常プレイストリームと同一に維持すると共に、このフレームのパケットを元の通常プレイストリームからのと同一のパケット距離で配置することにより達成することができる。
【０２４５】
この状況が、ＤＴＳまでの変更されない距離を示す図４３に示されている。ＤＴＳまでの距離は、図４３に示されるよりも大幅に大きくすることができる。
【０２４６】
図４３は、符号４３００で示された通常プレイにおける状況を示すと共に、符号４３０１で示されたスロー順送りにおける状況を示している。
【０２４７】
フレームデータの開始時点は、このフレームの開始におけるシステムタイムカウンタの値により与えられる。これは、事実上のＰＣＲ値ＰＣＲＳにより示される。上付文字Ｎ及びＳは、記録された通常プレイストリームにおける元の値及びスロー順送りストリームにおける新たな値を、各々、示す。この場合、フレームの開始に対する配置規則は、
ＤＴＳＳ−ＰＣＲＳＳ＝ＤＴＳＮ−ＰＣＲＳＮ （５）
により与えられ、これは、
ＤＴＳＳ−ＤＴＳＮ＝ＰＣＲＳＳ−ＰＣＲＳＮ （６）
に書き換えることができる。
【０２４８】
通常プレイストリームにおけるフレームの元の位置に対するスロー順送りストリームにおける該フレームのオフセット（offset）は、
offset＝ＰＣＲＳＳ−ＰＣＲＳＮ （７）
により与えられ、これは、
offset＝ＤＴＳＳ−ＤＴＳＮ （８）
に変形することができる。
【０２４９】
必要とされるＤＴＳ値は、各スロー順送りフレームに対して、及び、必要なら、ＧＯＰ内のＤＴＳを持たない通常プレイフレームに対しても計算することができる。通常プレイストリームにおける及びスロー順送りストリームにおける全ての元のフレームのＤＴＳが利用可能となるので、これらフレームのオフセットを、それらの新たな及び元のＤＴＳ値の間の差として計算することができる。次いで、このオフセットは、当該フレームを配置すると共に、このフレームのデータ内に存在するＰＣＲＳのＰＣＲ値を補正するために使用される。後者は容易である。即ち、オフセットが元のＰＣＲ値に単に加算される。ＰＣＲ拡張部は変更されない。これは、ＤＴＳとＰＣＲとの間にドリフトが生じないことを保証する。何故なら、当該補正が両ケースとも上記オフセットに等しいからである。この場合、新たな及び元のＰＣＲベース（base）値の間の関係は、
ＰＣＲbaseＳ＝ＰＣＲbaseＮ＋offset （９）
により与えられる。
【０２５０】
フレームの位置決めは、もっと幾らか困難である。位置決めは、全パケットに予め添付された4バイトの記録タイムスタンプ（ＴＳＴ）の補正により達成される。この目的のために、前記オフセットは９０ｋＨｚ基準から２７ＭＨｚ基準に再計算することができる。素直な選択は、上記オフセットを３００により乗算することであろう。しかしながら、この場合、通常プレイからスロー順送りに切り換える場合のＰＣＲクロック周波数の可能性のあるジャンプが考慮されねばならない。このようなジャンプは、そうあるべきように、タイムスタンプカウンタのクロックが記録の間にＰＣＲにロックされていたなら、決して発生しない。しかしながら、何らかの理由でタイムスタンプがＰＣＲにロックされていない場合、ジャンプするＰＣＲクロック周波数は、それでも、追加の乗算係数Ｍを使用することにより回避することができる。この場合、この係数は、記録された通常プレイストリームにおけるＰＣＲを含む最新の２つのパケットのタイムスタンプ及びＰＣＲ値の比に等しい。最新のとは、現フレームの開始前の最後の２つのＰＣＲパケットを意味する。この比は、ロックされたタイムスタンプの理想的な場合、１に等しくなる。これらの少なくとも２つのＰＣＲパケットをＰ（ｋ−１）及びＰｋにより示すと、当該フレームの全パケットのタイムスタンプに関するオフセットは、
ＴＳＴoffset＝３００ｘoffsetｘＭ （１０）
により与えられ、ここで、
Ｍ＝(ＴＳＴＮ{Ｐｋ}−ＴＳＴＮ{Ｐ(k-1)})／(ＰＣＲＮ{Ｐｋ}−ＰＣＲＮ{Ｐ(k-1)}) （１１）
である。
【０２５１】
この式におけるＰＣＲ値は、事実、２７ＭＨｚクロックに基づく全ＰＣＲ値となる。これは、ＰＣＲベース及び拡張から下記の方法で計算することができる：
ＰＣＲ＝３００ｘＰＣＲbase＋ＰＣＲext （１２）
【０２５２】
パケットＰ（ｋ−１）とＰｋとの間でＴＳＴ又はＰＣＲ値に折り返し（wrap）が存在するとＭの計算に変な結果生じ得ることは明らかである。これは、簡単に回避することができる。パケットＰｋに対する値がパケットＰ（ｋ−１）に対するより小さい場合、ＴＳＴ又はＰＣＲの範囲に対応する値が、この減算に先立ちパケットＰｋに対する値に加算されねばならない。これは、ＴＳＴ又はＰＣＲに対するレジスタは通常必要とされるよりも１ビット広くなければならないことを意味する。ＴＳＴに対しては、これは、この条件が生じた場合には上記追加ビットが１に設定され、それ以外ではゼロに設定されることも意味する。残りのビットは、常に、元のＴＳＴビットに等しい。
【０２５３】
計算されたＴＳＴオフセットは、このフレームの全パケットのタイムスタンプを補正するために使用される。これは、オフセット値が、記録されたタイムスタンプに加算されることを意味する。
【０２５４】
以下においては、Ｂフレームの繰り返しを説明する。
【０２５５】
Ｂフレームからの結果の表示画像の繰り返しは、Ｂフレームデータの繰り返しにより実施される。この結果、スロー順送りストリーム内に同一のＢフレームの系列が得られる。この系列の最初のフレームの配置は、元の通常プレイフレームの位置決めを扱う場合におけるのと類似する。残りのフレームは、反復Ｂフレームと呼ばれる。これらは、最初のフレームと同様に処理することができ、これは、オフセットがスロー順送りストリーム及び元の記録されたストリームにおけるＤＴＳ値の間の差として計算されることを意味する。記録されたフレームのＤＴＳは、同一のＢフレームの全系列に対して同一である。スロー順送りストリームにおいては、或るフレームのＤＴＳは、デルタにより増加された前のフレームのＤＴＳと常に等しくなる。これは、反復ＢフレームＢＲのオフセットも、下記の式により計算することができ、該式においてＢＬは前のＢフレームを示す：
offset{ＢＲ}＝offset{ＢＬ}＋Delta （１３）
【０２５６】
次いで、上記オフセットは、先に説明した態様で、特定のＢＲフレームのパケットの（変換後の）タイムスタンプ及び恐らくは現在のＰＣＲを補正するために使用される。
【０２５７】
図４４は、同一のＢフレームの系列の境界における等しいオフセットを示す。該状況は通常プレイに対して（符号４４００）及びスロー順送りに対して（符号４４０１）示されている。
【０２５８】
当該連結点に空フレームが挿入されないなら、或る系列の最初のＢフレームのオフセットは、スロー順送りストリームにおける前のフレームのオフセットと等しいことを示すことができる。２つの状況が、この要件を満たす。最初のものは、空フレームの事前挿入の場合にＢフレームが前のアンカフレームと連結される場合である。第2のものは、Ｂフレームが前のＢフレームと連結される場合である。図４４は、２つのＢフレームの連結に関する効果を示している。同一のことが、事実、系列の終了部にも当てはまる。また、ここでは、連結点の周りの２つのフレームのオフセットは、この点に空フレームが挿入されないなら同一となる。図４４も、これを２つの連結されたＢフレームに関して示している。他の状況は、Ｂフレームの後挿入が用いられる場合の、Ｂフレームの後続のアンカフレームへの連結である。
【０２５９】
これは、斯様な連結点の周りの２つのフレームが、通常プレイストリームにおけるのと同じ態様で接続されることを意味する。このような理由により、斯様な連結点においては、元のパケットが常に使用され、当該パケットが２つのフレームからの情報を含む場合における分割の結果としての２つのパケットは決して使用されない。また、（既に前述したように）斯様な点では接着が必要でないことも明らかである。全ての他の連結点では、もし存在するなら、分割からの２つのパケットが使用される。
【０２６０】
以下においては、Ｂフレームの時間圧縮を説明する。 Ｂフレームの持続時間が通常は1フレーム時間よりも小さいことが予測され得る。平均では、これは真であるが、時にはＢフレームの伝送時間は１フレーム時間よりも大きくなり得る。大凡３０秒の期間での測定において、１.４フレーム時間のＢフレームが検出された。この測定が図４５に示されている。平均のＢフレームデータ長は０.６フレームに等しいが、規則的に、Ｂフレームデータの持続時間は１フレーム時間より大きくなる。
【０２６１】
図４５は、時間が秒でプロットされた横軸を持つグラフ４５００を示す。該グラフ４５００の縦軸４５０２に沿って、フレームの長さがフレーム時間の数でプロットされている。
【０２６２】
Ｂフレームのパケットの、これらのタイムスタンプのＴＳＴオフセットでの補正による位置決めは、Ｂフレームの持続時間が１フレーム時間より短い限り、正しい結果となる。しかしながら、スロー順送りストリームにおけるＢフレームが１フレーム時間より大きい場合、該フレームの終了部が後続のフレームと重なる。何故なら、これらフレームの開始部は1フレーム時間の差で配置されるからである。これは、完全には正しくない。何故なら、最後の反復Ｂフレームは後続のフレームとは決して重ならないからである。１フレーム時間より大きなＢフレームに関する状況を図４６で明確にする。図４６は、Ｂフレームが１フレーム時間より大きな場合のデータの重なりを示す。
【０２６３】
図４６は、通常プレイの状況４６００、圧縮無しのスロー順送りの状況４６０１及び圧縮を伴うスロー順送りの状況４６０２を示す。フレーム時間は、符号４６０３により示される。Ｂフレームは符号４６０４を有し、次のフレームは符号４６０５を有し、前のフレームは符号４６０６を有し、圧縮されたＢフレームは符号４６０７により示されている。更に、隣接するフレームの間の重なりは符号４６０８により示されている。
【０２６４】
前及び次のフレームのタイプは、上述した効果には何の影響も有さない。従って、これらはアンカフレーム、Ｂフレーム又は空フレームとさえすることもできる。
【０２６５】
これは、同一のＢフレームの系列のうちの最後を除く全Ｂフレームは、時間的に圧縮されねばならないことを意味する。この圧縮は、局部的ビットレートを、全通常プレイストリームの概ね最大ビットレートのレベルまでさえ増加させ得る。この増加を可能な限り制限するために、Ｂフレームのパケットは利用可能なフレーム時間にわたり均等に分散される。Ｂフレームの最初のパケットのタイムスタンプは、先に示したオフセット規則で計算される。ＢフレームのパケットがＰｊにより示される場合（インデックスｊは当該Ｂフレーム内のパケット番号である）、スロー順送りストリームにおける圧縮されたＢフレームの最初のパケットのタイムスタンプは：
ＴＳＴＳ{Ｐ１}＝ＴＳＴＮ{Ｐ１}＋ＴＳＴoffset （１４）
により与えられる。
【０２６６】
当該フレームの後続するパケットに対するタイムスタンプの増加は、1フレーム時間を該フレームのパケット総数により除算したものに対応する値に等しい。接着パケット及びＰＣＲパケット等のＢフレームの終了部における追加のパケットは、この数に含まれなければならない。このパケットの数をＮｂにより示し、圧縮されたＢフレームのパケットの間の距離をｄｂにより示すと、この距離は：
ｄｂ＝３００ｘDelta／Ｎｂ （１５）
により与えられる。
【０２６７】
スロー順送りストリーム及び圧縮されたＢフレームの残りのパケットのタイムスタンプは、この場合：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄｂ （１６）
により与えられる。
【０２６８】
非理想的な場合、上記距離の計算のための乗算係数３００は、圧縮されたＢフレームの最後のパケットと後続のフレームの最初のパケットとの間のパケット距離の問題となり得る。これは、上記係数３００をとらず、代わりに上記デルタをオフセットに関して説明したのと同じ方法で変換することにより解決することができる。しかしながら、実用的な解決策は、パケットの実際の数より1だけ大きいＮｂの値をとることである。図４７は、不規則なパケット距離及び１フレーム時間より大きな持続時間を持つＢフレームが、如何にして、1フレーム時間の持続時間及び一定のパケット距離を持つＢフレームに圧縮されるかを示す。1フレーム時間は、タイムスタンプの３００ｘDeltaの増加に対応する。Ｎｂがパケットの実際の数より１だけ大きくなるように選択される事実の結果、圧縮されたＢフレームの終了部に幾らかの空きスペースが得られる。
【０２６９】
従って、図４７は均一に分布されたパケットを持つＢフレームの圧縮を示す。
【０２７０】
図４７は、圧縮されていない状態４７００及び圧縮された状態４７０１を示すと共に、Ｂフレーム４７０２及び１フレーム時間内に圧縮されたＢフレーム４７０３を示す。
【０２７１】
Ｂフレームに対する等しいパケット分布の方法を、圧縮が必要とされる場合のみでなく全ての場合に使用することができる。しかしながら、殆どの場合では、これはＢフレームが伸張されることを意味する。Ｂフレームの最初のパケットに対するＴＳＴオフセットの適用は、このパケットのＤＴＳまでの距離が通常プレイストリームに等しいことを意味する。この場合、伸張の結果、当該Ｂフレームデータの終了部と対応するＤＴＳとの間において元のものより時間距離が小さくなる。しかしながら、フレームのＤＴＳは当該フレームデータの開始の１フレーム時間よりは決して早くなり得ないことを理解することができる。その理由は下記の通りである。元のストリーム及びフレームのＤＴＳは、定義により、前のフレームのＤＴＳより常に１フレーム時間遅い。この前のフレームのＤＴＳは、このフレームのデータの終了より決して早いことはあり得ず、従って現フレームのデータの開始よりも決して前ではない。これは、任意のフレームのＤＴＳは、このフレームのデータの開始より少なくとも１フレーム時間遅いことを意味する。これは、フレームデータが１フレーム時間内に均一に分布されていても、常に該フレームデータの終了より後であることも意味する。従って、説明した等しいパケット分布は、最後の反復Ｂフレームを除く全てのＢフレームに適用されるべきである。簡略化のために、圧縮され及び伸張されたフレームは圧縮されたフレームと称することができる。
【０２７２】
接着は、Ｂフレームの等しい系列におけるＢフレームの間においてのみ必要である。従って、可能性のある追加の接着パケットは、圧縮されたＢフレームの終わりにのみ追加され、それ以外では決して追加されない。付加的ＰＣＲパケットは、最後の反復Ｂフレームの終わりを除き、Ｂフレームの終わりに追加される。何故なら、この点には空きがないからである。これは、付加的ＰＣＲは圧縮されたＢフレームの終了部においてのみ追加されることも意味する。従って、これらのパケットに対しては特別な配置アルゴリズムは必要ではない。何故なら、これらは全て圧縮アルゴリズムに含まれるからである。
【０２７３】
Ｂフレームの圧縮の結果は、フレームデータ内のＰＣＲの値の補正は、最早、斯様なＢフレームにとり正しくないということである。この場合において該ＰＣＲ値が如何にして補正されるか、及び圧縮されたＢフレームの終了部に追加されるＰＣＲの値が如何にして計算されるかを、以下に説明する。次いで、空フレームの挿入が説明される。
【０２７４】
挿入される空フレームが何処に配置されるかを決定しなければならない。スロー順送りストリームにおける他のフレームの位置を考察すると、特に大きなスローモーション係数の場合は、主な時間間隙は空フレームが挿入されるべき箇所に存在することが明らかである。過度のＰＣＲ距離による問題を避けるために、空フレームは、この領域内に分散されねばならず、且つ、各空フレームはＰＣＲを含まなければならない。このような理由により、連続する空フレームの間の距離は、1フレーム時間となるように選定される。最初の空フレームは、前のフレームに直接連結される。これが、図４８に示される。
【０２７５】
図４８は、空フレームの配置を示し、前のフレーム４８００、空フレーム４８０１、フレーム時間４８０２後の更なる空フレーム４８０１が配置される等々のシーケンスを示している。次のフレームは符号４８０３により示されている。
【０２７６】
配置アルゴリズムは、空フレームの事前若しくは事後挿入又はタイプには無関係である。しかしながら、空フレームの最初のパケットの配置と、残りのパケットの配置との間は区別されるべきである。
【０２７７】
以下においては、空フレームの最初のパケットの配置を説明する。
【０２７８】
図４９から分かるように、ここでは、空フレームの最初のパケットの位置決めを説明する。前のフレーム４９００には、複数の空フレーム４９０１、４９０２、４９０３等々が後続する。空フレームの最初のパケットはＦＰｉにより示され、ここで、ｉは空フレームのシーケンス内での当該空フレームのフレーム番号である。
【０２７９】
最初の空フレームの最初のパケットであるＦＰ１の配置で開始すると、このパケットのタイムスタンプを導出する幾つかのオプションが存在する。その１つは、先行するフレームの最後のパケットのスロー順送りタイムスタンプに値ｄを加算することである。この最後のパケットをＰＬとして示すと、最初の空フレームの最初のパケットのタイムスタンプは、
ＴＳＴＳ{ＦＰ１}＝ＴＳＴＳ{ＰＬ}＋ｄ （１７）
により与えられる。
【０２８０】
上記ｄなる値も、幾つかの方法で選択することができる。或る可能性は、先行するフレームの最後の２つのパケットのタイムスタンプの間の差を、ｄのための値として使用することである。この場合、これらタイムスタンプは、スロー順送りストリームから又は元の記録されたストリームからの何れかから取り出すことができる。何故なら、圧縮されたフレームは、いずれにせよ、空フレームに決して先行することはないからである。前のフレームの最後の２つのパケットをＰ(L-1)及びＰＬにより示すと、ｄの値は、
ｄ＝ＴＳＴ{ＰＬ}−ＴＳＴ{Ｐ(L-1)} （１８）
により与えられる。
【０２８１】
ｄの計算のためのタイムスタンプがスロー順送りストリームから取り出される場合、ＦＰ１の計算のための前記式も：
ＴＳＴＳ{ＦＰ１}＝２ｘＴＳＴＳ{ＰＬ}−ＴＳＴＳ{Ｐ(L-1)} （１９）
と書くことができる。
【０２８２】
後続の空フレームの最初のパケットのタイムスタンプは、ＦＰ１のタイムスタンプに対する１フレーム時間に対応する値の反復的加算により得ることができる。この値は、この場合、３００ｘDeltaとなるように選択することができる。かくして、後続する空フレームの最初のパケットのタイムスタンプは：
ＴＳＴＳ{ＦＰｉ}＝ＴＳＴＳ{ＦＰ(i-1)}＋３００ｘDelta （２０）
により与えられる。
【０２８３】
以下においては、空フレームの残りのパケットの配置を説明する。
【０２８４】
空フレームのパケットはＰｊにより示され、ここで、ｊは該空フレーム内のパケット番号である。Ｐ１は、上記においてＦＰにより示された空フレームの最初のパケットである。
【０２８５】
残りのパケットの位置は、空フレームの最初のパケットから導出される。このために、パケット間の距離が決定されねばならない。これは、事実、該距離が短すぎない限り厳しくはない。何故なら、十分な空間が利用可能であるからである。ここでは、２つのオプションを述べる。
【０２８６】
第１のオプションは、先に述べたｄなる値をここでも使用することである。この場合、この値は、空フレーム内のパケットのタイムスタンプを増加させるために使用される。かくして、これらタイムスタンプは：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄ （２１）
により与えられる。
【０２８７】
これが図５０に示され、該図は前のフレーム５０００、第１の空フレーム５００１及び第２の空フレーム５００２のシーケンスを示している。従って、図５０は、前のフレームに基づく空フレームのパケット距離を示す。
【０２８８】
第２のオプションは、空フレームのパケットを１フレーム時間にわたり均一に分散させることである。この場合、増分は、当該空フレームのパケット数により除算された１フレーム時間に対応する値に等しい。このパケット数をＮｅにより、パケット間の距離をｄｅにより各々示すと、該距離は：
ｄｅ＝３００ｘDelta／Ｎｅ （２２）
により与えられる。
【０２８９】
この場合、空フレーム内のパケットのタイムスタンプは：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄｅ （２３）
により与えられる。
【０２９０】
この状況が図５１にも示され、該図は前のフレーム５０００が第１の空フレーム５００１及び第２の空フレーム５００２により後続されるのを再び示している。
【０２９１】
従って、図５１は１フレーム時間にわたり均一に分散された空フレームのパケットを示す。
【０２９２】
次に、ＰＣＲに関する幾つかの態様を説明する。
【０２９３】
先ず、スロー順送りストリームには追加のＰＣＲは挿入されないと仮定することができる。Ｉフレームは通常は１フレーム時間より大幅に大きいので、該フレームがＰＣＲを含むことは非常にありそうなことである。Ｐフレームの場合、確率は早くも低減される。Ｂフレームは殆どの場合１フレーム時間より小さいので、多くのＢフレームはＰＣＲを含まないであろう。これは、Ｂフレームが繰り返されたとしても、スロー順送りストリームではＰＣＲの大きなギャップが生じるであろうことを意味する。一般的に、ＰＣＲ間の最大距離は、スローモーション係数により増加されると言うことができる。これは、明らかに、スロー順送りストリームへの追加のＰＣＲの挿入を必要とする。
【０２９４】
フレームデータに埋め込まれた元のＰＣＲとは別に、付加的ＰＣＲが空フレーム及びＢフレームの終わりに追加されねばならない。後者は最後の反復Ｂフレームの終わりを除いて成り立つ。何故なら、この点には空きはないからである。これら対策によっても、上記最大距離が、問題となるレベルまでではないが、依然としてＤＶＢ規格の要件を超過する可能性がある。一般的に、当該状況は高速順送り／高速逆送りに対するよりは有利である。
【０２９５】
フレームに埋め込まれたＰＣＲの補正は、少なくとも圧縮無しのフレームに関しては先に説明した。何らかの他の方法が、空フレームにおける及びＢフレームの終わりにおける付加的ＰＣＲのＰＣＲ値を計算するために並びに圧縮されたＢフレーム内のＰＣＲのために有利である。第１のオプションは下記の規則である。即ち、ＰＣＲ値は、スロー順送りストリームにおける前のＰＣＲの、これらＰＣＲを含む２つのパケットの実際のスロー順送りタイムスタンプの間の差で補正された値に等しい。現ＰＣＲ及び前のＰＣＲを含むパケットを、各々、Ｐｃ及びＰ(c-1)により表すと、スロー順送りストリームにおける現ＰＣＲは：
ＰＣＲＳ{Ｐｃ}＝ＰＣＲＳ{Ｐ(c-1)}＋ＴＳＴＳ{Ｐｃ}−ＴＳＴＳ{Ｐ(c-1)} （２４）
により与えられる。
【０２９６】
ここでも、ＰＣＲはベース及び拡張部から計算された全ＰＣＲ値を指す。この式は、理想的な場合は完全であるが、非理想的な場合は周波数変動、従ってかなりのＰＣＲジッタにつながる。これは、先に計算された補正係数Ｍを適用することにより防止される。現ＰＣＲは：
ＰＣＲＳ{Ｐｃ}＝ＰＣＲＳ{Ｐ(c-1)}＋(ＴＳＴＳ{Ｐｃ}−ＴＳＴＳ{Ｐ(c-1)})／Ｍ （２５）
により与えられた。
【０２９７】
当該パケットに挿入されるべきＰＣＲのベース及び拡張部はＰＣＲ値から下記のようにして計算される：
ＰＣＲbase＝int(ＰＣＲ／３００) （２６）
ＰＣＲext ＝ＰＣＲ−３００ｘＰＣＲbase （２７）
【０２９８】
事実、式（２６）及び（２７）は全てのＰＣＲ値を調整するために使用され得るので、圧縮されていない元のフレームに埋め込まれたＰＣＲのものも含む。しかしながら、前記補正係数による計算は丸め誤差につながり得、これら誤差は蓄積し得るので、ＤＴＳに対してＰＣＲタイムベースのゆっくりしたドリフトが生じ得る。従って、このドリフトをゼロにリセットするために、圧縮されていないフレームに埋め込まれたＰＣＲの補正が、先に説明したようにオフセット値の加算により実行されねばならない。
【０２９９】
以下においては、ハイブリッドストリームが何処で作成され得るかを説明する。
【０３００】
ここで述べるハイブリッドストリームは幾つかの場所で作成することができる。これらは、事実、平文Ｉフレームを持つストリームに対して可能なのと同一の場所である：
１．衛星放送の場合における放送機又はアップリンクにおいて；
２．ケーブルネットワークの場合におけるケーブルヘッドエンドにおいて；
３．安全な認可ドメインの場合における住宅用ゲートウェイにおいて；
４．記憶装置の記録側において。
しかしながら、僅かな平文パケットしか伴わないストリームの場合、第５の場所、即ち：
５．記憶装置の再生側において、
が可能である。
【０３０１】
図５２は、ハイブリッドストリームへの変換にとり可能性のある場所を示す。
【０３０２】
図５２の状況は、放送機５２００が衛星アンテナ５２０１に信号を放送するものである。衛星アンテナ５２０１は該信号を衛星５２０２に送信することができ、他の衛星アンテナ５２０３が、これら信号を受信することができる。次いで、斯かる信号はケーブルヘッドエンド５２０４に供給することができ、該ケーブルヘッドエンドから記憶装置５２０５に供給することができる。又は、上記信号は住宅用ゲートウェイ５２０６に供給することができ、該ゲートウェイから記憶装置５２０７に供給することができる。他の例として、上記信号は衛星アンテナ５２０３から記憶装置５２０８に供給することもできる。図５２の位置１〜５において、ハイブリッドストリームへの変換が可能である。
【０３０３】
位置１及び２は実現するのが困難であろう。何故なら、プロバイダはここには限られた影響しか有さないからである。記憶装置にとっては、ハイブリッドストリームへの変換が位置１、２又は３で実現されるかは、実際に、差はない。オプション３は、良い代替となる。これは、認可されたドメインのための住宅用ゲートウェイにおけるプロバイダの立場を改善し得る。３つの全ての場合において、記憶装置は自身の記録入力端においてハイブリッドストリームを受信する。これは、少なくとも通常プレイ及びトリックプレイの発生のためでないなら、記憶装置に解読及びスマートカードは必要でないことを意味する。しかしながら、キーフレーム等の検出を用いる記憶装置内にメタデータ抽出機能が存在する場合、解読は依然として必要である。
【０３０４】
ハイブリッドストリームを構築するために非常にありそうな位置は、記憶装置の記録側にあるケース４であろう。これは、記録側における部分的解読を必要とするかも知れないが、トリックプレイの発生のために解読が必要とされないという利点を依然として有している。いずれにせよ、記録されるストリームはハイブリッドストリームであることが好ましい。
【０３０５】
記録が全パケットが暗号化された状態でなされるケース５においても、安全なトリックプレイを生成することは可能である。完全な解読の代わりに、必要とされるパケットのみを解読し、残りを依然として暗号化されたままにすることも可能である（図５３参照）。
【０３０６】
図５３は、完全に暗号化された記録から安全なトリックプレイを発生するものを示している。記録装置５３００は、暗号化されたＭＰＥＧ２データ５３０１を出力し、後者をブロック選択器ユニット５３０２に供給する。そこから、データは解読器５３０３に供給され、該解読器は部分的に暗号化されたＭＰＥＧ２データ５３０４を発生する。この部分的に暗号化されたＭＰＥＧ２データはフレーム選択器５３０５に供給され、そこから、該データはトリックプレイ発生ユニット５３０６に供給される。トリックプレイ発生ユニット５３０６は、ＭＰＥＧ２ ＤＶＢ準拠のトランスポートストリームの部分的に暗号化されたデータ５３０７を発生し、該データは次いでＭＰＥＧ２デコーダ又は解読器５３０８に供給することができる。
【０３０７】
しかしながら、これらのパケット及び平文と共に記録することにより可能であるような、前もってＣＰＩ（図４参照）を作成する利点は利用することはできない。しかしながら、支配的に暗号化されたトリックプレイストリームを作成することは依然として可能である。当該システム構成は、トリックプレイ構築ユニットが、トランスポートストリームレベルで構築された暗号化されたストリームを発生し、ＥＣＭの挿入がオプションではなく必須であるというようなものである。
【０３０８】
以下においては、平文であるべきパケットを如何にして選択するかを説明する。
【０３０９】
ハイブリッドストリームが構築される場合、どのパケットが平文でなければならないかが決定されねばならない。必要とされる平文データの検出及び選択を可能にするために、当該ビデオストリームを先ず完全に解読することができる。次いで、このデータの位置が該平文ストリーム内で決定され、該データが位置する平文パケットが元のストリームの暗号化されたパケットを置換してハイブリッドストリームを形成する。
【０３１０】
選択された平文データに対して、３つの規準を使用することができる：
１．存在するなら、ＤＴＳ／ＰＴＳ及びＰＥＳヘッダは変更することができる。この目的のために、ＰＥＳヘッダデータの全てを平文にすることができる。これは、PLUSIビット組を持つものからＰＥＳヘッダの最後のバイトを含むものまでの範囲のパケットが全て平文にされることを意味する。
２．シーケンスヘッダ及びシーケンス拡張部からの何らかの情報は必要とされ得る。この目的のために、シーケンスヘッダから画像開始コードまでのデータの全てが平文にされる。シーケンスヘッダ及び画像開始コードは、４バイトコードをチェックすることにより検出される。これらの４バイトは、必ずしも、１つの同一のパケットに位置するとは限らない。シーケンスヘッダ及び画像開始コードは、斯かる４バイトの最後が見つかった場合に検出される。ハイブリッドストリームの構築のための過度のバッファリングを避けるために、シーケンスヘッダの４バイトを含むものから画像開始コードの４バイトを含むものまでの範囲のパケットが全て平文にされる。これは、結果としてのハイブリッドストリームにおいてシーケンスヘッダ及び画像開始コードを検索する場合に、幾つかの変な状況につながり得る。これは後述する。
３．画像開始コードは、フレーム境界を検出するために必要とされる。従って、画像開始コードを含むパケットは平文にされなければならない。画像開始コードに続く２バイトも、平文でなければならない。これらのバイトは、変更される必要があり得る時間基準、及びＩフレーム、Ｐフレーム又はＢフレームを識別する画像符号化タイプを含む。更に、幾らかの情報が、画像コード拡張部から必要である。この目的のために、画像開始コードから画像コード拡張部の終わりまでのデータの全てが平文にされる。画像開始コードは、前記４バイトが発見された場合に検出される。過度のバッファリングを避けるために、画像開始コードの４バイトを含むものから画像コード拡張部の最後のバイトを含むものまでの範囲のパケットが全て平文にされる。この結果、全てのフレーム境界上で平文パケットとなり、これは特定のトリックプレイストリームの構築に必要とされるもの以上のものである。しかしながら、これはスローモーション順送りストリームの構築には必要である。
【０３１１】
過度のバッファリングが何を意味するか、及びこれが何を生じるかの問題に関して、ハイブリッドストリームが構築される場合、元の暗号化されたストリーム及び解読されたストリームからのパケットが１つのストリームに結合されねばならないと言うことができる。リアルタイムに実行される場合、何らかのバッファリングが必要とされ得る。画像開始コードが２つのビデオパケット上に分散されていると仮定すると、この４バイトの画像開始コードは暗号化されたストリームにおいて最後のバイトが見つかった時点で検出される。完全な画像開始コード及び平文を有するということは、この最後のバイトを持つビデオパケットのみならず、先行するビデオパケットも平文でなければならないことを意味する。
【０３１２】
これらの２つのビデオパケットの間に他のデータがあい得、通常はあるであろう。基本的に、これは大量のパケットであり得る。図５４は、Ｉフレームの終わりの画像開始コードが２ビデオパケットにわたって広がっているような状況の一例を示している。
【０３１３】
更に詳細には、図５４は、画像開始コード５４０２の一部を含むようなＩフレーム５４０１を含むバッファ５４００を示す。次いで、オーディオパケット５４０３が後続する。バッファ５４００に更に含まれるものは、ＰＳＩブロック５４０４及びデータブロック５４０５である。図５４には、画像開始コード検出時点５４０６、画像開始コードの一部５４０７及び後続のＰフレーム５４０８も更に示されている。
【０３１４】
図５４の場合、これら２つのビデオパケットのみならず、これら２つのビデオパケット間の他のデータの全てのパケットもバッファリングされねばならない。該例では、画像開始コードが示されているが、同じ議論がシーケンスヘッダコードに対しても有効であることは明らかである。示された規準は、必要なバッファリングを１パケットのみに低減する。
【０３１５】
３つの定義された規準の１つが満たされたなら、対応するパケットが平文にされる。３つの規準の組み合わせの結果、しばしば、各フレーム境界において１つのみの平文パケットとなる。しかしながら、何らかのストリームに対する幾つかの実際的ケースでは、数個のパケットでもあり得る。事実、理論的に、これは多数のパケットでさえあり得る。
【０３１６】
第１の例は、ＧＯＰ当たり１ＰＥＳパケットで、例えば１２フレームのＧＯＰサイズのＩフレーム及びＰフレームのみからなるストリームである。なされた実験において、Ｉフレームの開始における平文パケットの数は常に１であった。Ｉフレームの終わりにおける、及び実際には全ての他のフレーム境界における平文パケットの数は通常は１であったが、時には２であった。Ｉフレームの開始において、ＰＥＳヘッダから画像コード拡張部までの全てのものは１パケット内である。他のフレーム境界における平文パケットは、画像開始コードから画像符号化拡張部の終わりまでの全データを含む。このデータは、２つのパケットにわたり分散させることができる。
【０３１７】
第２の例は、フレーム当たり１ＰＥＳパケットで、２から１２までの範囲の偶数値を持つ変化するＧＯＰサイズの、ＩＢＰ構造によるＩフレーム、Ｐフレーム及びＢフレームを有するようなストリームである。このストリームは、実際には、平文ストリームであるが、ここでは、暗号化されているかのように使用される。Ｉフレームの開始における平文パケットの数は殆どの場合２であり、Ｉフレームの終わり及び他のフレーム境界では常に１である。Ｉフレームの開始における上記２つのパケットは、主に、量子化テーブル及びシーケンスヘッダの存在によるものである。Ｉフレームの終わり及び他のフレーム境界において、ＰＥＳヘッダから画像符号化拡張部までのデータは全て１パケット内である。
【０３１８】
ＰＥＳ構造により、平文であるのはＩフレームの最後のパケットではなく、実際には次のフレームの最初のパケットであることに注意すべきである。これは、他の筋書きでも発生し得る。しかしながら、これは問題ではない。何故なら、この場合、Ｉフレームの最後のパケットはＩフレームデータのみを含み、除去される必要はないからである。
【０３１９】
また、実際には、前記３つの規準の組み合わせが各フレーム境界において１つの連続した平文ビデオ領域になることにも注意すべきである。理論的に、これが当てはまる必要はない。規準２及び３の組み合わせは、常に、連続した領域となるが、理論的に平文ＰＥＳヘッダ領域は別のものとすることができる。
【０３２０】
以下においては、ハイブリッドストリームにおいて必要な情報を如何にして見つけるかを説明する。
【０３２１】
実際には、各フレーム境界に１つの連続した平文領域が存在する。Ｉフレーム（ＧＯＰ）の開始部において、該平文領域はＰＥＳヘッダの最初のバイトから少なくとも画像符号化拡張部の最後のバイトまで続く。
【０３２２】
一例が図５５に示される。
【０３２３】
図５５は、Ｉフレームの開始部における実際的な平文領域を示す。図５５に示されるデータシーケンスは、ＰＥＳヘッダ５５００、シーケンスヘッダ５５０１、シーケンス拡張部５５０２、ＧＯＰヘッダ５５０３、画像開始コード５５０４、画像ヘッダ５５０５、他の画像ヘッダ５５０６、画像符号化拡張部５５０７、及びＩフレームデータ５５０８を含む。
【０３２４】
構成成分５５００〜５５０５は第１のＩフレームパケット５５０９に関するもので、構成成分５５０６〜５５０８は第２のＩフレームパケット５５１０に関するものである。
【０３２５】
全ての必要なデータは、この領域内にあり、当該ストリームのPLUSIにより印されたパケットで開始する該部分を解析することにより容易に見つけることができる。
【０３２６】
Ｉフレームの終了部では、２つの可能性がある：
１．フレーム当たり１ＰＥＳパケットの場合、Ｉフレームの終了部（の後の）平文領域のエッジもＰＥＳヘッダの第１バイトで開始し、少なくとも画像符号化拡張部の最後のバイトまで延びる。全ての必要なデータは容易に見つかり、Ｉフレームの最後のパケットの削除（cleaning）は必要とされない（図５６の左側参照）。
２．ＧＯＰ当たり１ＰＥＳパケットの場合、Ｉフレームの終わりより後にはＰＥＳヘッダは存在しない。実際には、この位置にはシーケンスヘッダもない。この場合、画像開始コードの第４バイトから画像符号化拡張部の最後のバイトまでを含むパケットは、平文である（図５６の右側参照）。画像開始コードの４つのバイトは、例えば最初の３バイトが或るパケット内に、最後のバイトが次のパケット内のように、２つのパケットに渡って分散することができる。この場合、最初の３つのバイトは依然として暗号化されている。これは、この画像開始コードを検出することができないことを意味するように見える。
【０３２７】
図５６は、実際の平文領域を示す。図５６のシーケンスには、Ｉフレームの終わり５６００、PLUSIプレゼント５６０１、ＰＥＳヘッダ５６０２、画像開始コード５６０３、画像ヘッダ５６０４、画像符号化拡張部５６０５、Ｐフレーム又はＢフレームデータ５６０６、最後のＩフレームデータ５６０７、Ｉフレームの終わり５６０８、画像開始コード５６０９、画像ヘッダ５６１０、画像符号化拡張部５６１１、及びＰフレーム又はＢフレームデータ５６１２が示されている。
【０３２８】
実際に、各フレーム境界には平文領域が存在する。従って、Ｉフレームの終了部の検出は、Ｉフレームのものより後の最初の画像開始コードの検索を意味する。暗号化されたデータにおける誤った肯定的合致を回避するために、このコードに関して平文ビデオパケットのみが検索されるべきであることは明らかであろう。パケットのペイロードが平文であるか否かは、パケットヘッダにおけるスクランブル制御ビットにより示される。検出は、４つのバイトの所与のシーケンス（0x00 0x00 0x01 0x00）が見つかった場合にのみ肯定的合致を示す。該シーケンスは、フレームのタイプを無視した画像開始コードに対応する。残念ながら、画像開始コードは、トランスポートストリームパケットの境界上に整列される必要はない。これは、画像開始コードが２つのパケットにわたって分散されたとしたら、これらパケットのうちの第２のものだけが平文であろうことを意味する。
【０３２９】
これが、図５７に示されている。
【０３３０】
問題は、符号５７００により示された２つの部分が、誤った肯定的合致を与えるかである。図５７において、パケットヘッダは符号５７０１により示され、平文のパケットペイロードは符号５７０２により示され、暗号化されたパケットペイロードは符号５７０３により示されている。
【０３３１】
一番上のライン５７０４は、完全に第２パケット内に位置する画像開始コードを示す。一番下のライン５７０５の場合、画像開始コードは完全に第１のパケット内にある。残りのライン５７０６は、分散された画像開始コードの３つの可能性を示す。
【０３３２】
部分的に暗号化された画像開始コードを検出することは不可能であると予測されるかも知れない。しかしながら、このジレンマから抜け出す方法がある。各平文領域は、画像開始コード又は少なくともその最後のバイトを含まなければならない。従って、或る平文領域において画像開始コードが見つからない場合、この領域は画像開始コードの最後のバイトの幾つかで開始している筈であることがわかる。このバイト数は、図５７に示すように、１、２又は３である。実際に、どれだけ多くのバイトが存在するかを正確に検出することが可能である。この点に関しては、画像符号化タイプの３つのビットが全てゼロであることは決してあり得ないことに注意することが重要である。何故なら、これはＭＰＥＧ２規格により禁止されているからである。従って、図５７に0xYYにより示された画像開始コードの第2バイトは決して0x00にはなり得ない。従って、当該平文領域が0x00 0x01 0x00で開始した場合、これらは画像開始コードの最後の3バイトである。該領域が0x01 0x00で開始した場合、これらは最後の2バイトである。該領域が0x00 0x01 0x00ではなく、0x00で開始した場合、最後のバイトのみが存在する。このようにして、何処に画像開始コードが位置するかが正確に分かり、これに続くデータを解析することができる。もし必要又は望むなら、画像タイプはバイト0xYYから読み取ることができる。
【０３３３】
また、画像開始コードが２つのパケットに渡って分散されている場合、Ｉフレームの最後のパケットを全ての非Ｉフレームデータを削除することにより除去することは可能ではなさそうだと言うこともできる。これは、実際に正しい。何故なら、画像開始コードの暗号化された部分を削除することは可能ではないからである。しかしながら、トリックプレイストリームの構築においては、空のＰフレームがＩフレームの最後に付加されるであろう。この空Ｐフレームは画像開始コードで始まるであろう。従って、画像開始コードの暗号化されたバイトは再使用することができる。何故なら、これらのバイトのいくつが、最後の暗号化されたパケットの終了部に存在するかが分かるからである。この数のバイトは、Ｉフレームの後に追加されるべき最初の空Ｐフレームの画像開始コードから削除される。
【０３３４】
図５８は、このような状況の一例を示す。
【０３３５】
図５８には、部分的に暗号化された画像開始コードに付加された空のＰフレームが示されている。画像開始コードは符号５８００により示されている。図５８には、時間基準５８０１も示されている。更に、画像符号化タイプが符号５８０２により示されている。空フレームのデータは符号５８０３により示されている。
【０３３６】
実際に予測されるべき状況を上述したが、理論的には幾つかの付加的状況が生じ得る。これは、平文ＰＥＳヘッダ領域と規準２及び３からの結果の平文領域とが、理論的に接続される必要がなく、暗号化されたビデオパケットにより分離され得るという事実から生じる。明瞭化のために、連続する平文領域とは、ビデオパケットのシーケンスは平文であるが、他の暗号化されたパケットが間に存在し得ることを意味することに言及すべきであろう。
【０３３７】
前記規準に従って、アクセスされるべき３つの重要なデータ領域が存在する：
１．ＰＥＳヘッダ領域；
２．シーケンスヘッダ及びシーケンス拡張部における情報；
３．画像開始コードから画像符号化拡張部までの情報。
【０３３８】
これら３つのデータ領域が図５９に示されている。
【０３３９】
図５９は、上記３つの規準に対応する平文データ領域を示す。第１の構成は、PLUSIプレゼント５９００及びＰＥＳヘッダ５９０１を示す。第２の画像は、シーケンスヘッダコード５９１０、シーケンスヘッダ５９１１、シーケンス拡張コード５９１２及びシーケンス拡張部５９１３を示す。画像開始コード５９１４が更に示されている。
【０３４０】
図５９における第３の画像は、画像開始コード５９２０、画像ヘッダ５９２１、画像符号化拡張コード５９２２及び画像符号化拡張部５９２３を示している。
【０３４１】
このデータを位置特定すると共に正しく受け渡すために、当該ストリームにおいて３つの項目が見つけられなければならない：
１．パケットヘッダにおけるPLUSIビット；
２．シーケンスヘッダコード（0x00 0x00 0x01 0xB3）；
３．画像開始コード（0x00 0x00 0x01 0x00）。
【０３４２】
項目１を見つけることは、単にPLUSIビット及びパケットヘッダを探すだけで容易であり、これが１に設定されていたら、パケットはＰＥＳヘッダで開始し、次いでこれを渡すことができる。項目２及び３に関する状況は、もっと複雑である。何故なら、シーケンスヘッダコード及び画像開始コードは２つのパケットにわたって分散され、結果として部分的に暗号化されたコードである可能性があるからである。従って、これらコードの直接的検出は、データの何らかの喪失につながる。しかしながら、この問題に対する解決策が存在する。ＭＰＥＧ２においては、シーケンス拡張部及び画像符号化拡張部の存在は、図６０に示されるように、必須である。
【０３４３】
図６０は、ＭＰＥＧ２におけるヘッダ構造を示し、該構造は、シーケンスヘッダユニット６０００、シーケンス拡張ユニット６００１、拡張及びユーザユニット６００２、画像群ヘッダユニット６００３、ユーザユニット６００４、画像ヘッダユニット６００５、画像符号化拡張ユニット６００６、ユーザユニット６００７、画像データユニット６００８及びシーケンス終了ユニット６００９を含む。
【０３４４】
平文パケットに対する規準が形成された態様は、これら拡張部が完全に平文であることを保証することができる。これらは、先ず0x00 0x00 0x01 0xB5である拡張開始コードを検索することにより見つけることができる。次の４ビットは拡張開始コード識別子である。これらの４ビットは、シーケンス拡張部に対しては0001であり、画像符号化拡張部に対しては1000である。シーケンス拡張部が存在する場合、シーケンスヘッダコードも存在すべきであり、同様に、画像コード拡張部が存在するなら、画像開始コードも存在すべきである。この結果、下記のようになる：
− シーケンス拡張部が平文領域で見つかるが、シーケンスヘッダコードが同じ領域で見つからない場合、該シーケンスヘッダコードは２つのパケットにわたって分散されているべきであり、該シーケンスヘッダコードの最後のバイト又は複数のバイトは、可能性のあるＰＥＳヘッダを無視すると、この平文領域の最初のバイトである（シーケンスヘッダコード６１００、シーケンスヘッダ６１０１及びシーケンス拡張部６１０２を示す図６１参照）。
− 画像符号化拡張部が平文領域で見つかるが、画像開始コードが同じ領域で見つからない場合、該画像開始コードは２つのパケットにわたって分散されているべきであり、該画像開始コードの最後のバイト又は複数のバイトは、可能性のあるＰＥＳヘッダを無視すると、この平文領域の最初のバイトである（画像開始コード６２００、画像ヘッダ６２０１及び画像符号化拡張部６２０２を示す図６２参照）。
【０３４５】
これらの２つの状況は、１つの平文領域においては決して同時に発生し得ないことに注意すべきである。シーケンス拡張部及び画像符号化拡張部が共に存在する場合、これらの２つの間に位置される画像開始コードは必然的に完全に平文であろう。この場合、シーケンスヘッダコードのみが部分的に暗号化されている可能性がある。勿論、シーケンスヘッダコード又は画像開始コードが完全に平文であり、従って素直な態様で検出される場合、対応するデータの受け渡しは即座に開始することができる。しかしながら、上述した状況の一方に遭遇した場合、正しい受け渡しを開始することができる前に、これらコードのうちのどれだけ多くのバイトが当該平文領域の開始部に又はＰＥＳヘッダの後にあるかが先ず分からねばならない。画像開始コードに関してこれを検出する方法は、シーケンスヘッダコードに対しても適用することができる。
【０３４６】
図６３は、２つのパケットにわたって分散されたシーケンスヘッダコードを示す。
【０３４７】
シーケンスヘッダコードに対する状況が、図６３に示されている。平文は、4番目のバイトから以降にのみ保証される。このバイトは、0x00 0x00 0x01 0xB3に等しいシーケンスヘッダコードの最後のバイトである。従って、シーケンスヘッダコードは存在するが、この領域では検出されない場合、該コードの最後のバイトの幾つかは、この領域の開始部に又はＰＥＳヘッダの後に存在しなければならない。画像開始コードと同様に、これらバイトのうちの幾つが存在するかを正確に検出することができる。検出は、ＰＥＳヘッダを無視して、当該領域における最初の平文バイトで開始する。最初のバイトが0x00 0x01 0xB3なら、3バイトが存在し、これらが0x01 0xB3なら、２バイトが存在し、最初のバイトが0xB3なら、この１バイトのみが存在する。該バイト数、従ってシーケンスヘッダコードの最後のバイトの位置が分かれば、画像開始コードが、このコードに続くデータの正しい受け渡しを可能にする。
【０３４８】
当該明細書で使用される略語のリストが表１に示される。
【表１】
【０３４９】
尚、上述した実施例は本発明を限定するというよりは解説するものであり、当業者であれば添付請求項に記載した本発明の範囲から逸脱することなしに多数の代替実施例を設計することができることに注意されたい。更に、上述した実施例の何れかは、例えば電池又は蓄積器等の内部電流供給部のような暗黙的特徴部を有するものである。また、請求項において、括弧内の如何なる符号も斯かる請求項を限定するものと見なしてはならない。また、"有する"等の用語は、如何なる請求項又は明細書全体に掲載されたもの以外の構成要素又はステップの存在を排除するものではない。また、単数形の構成要素は、複数の斯様な構成要素の存在を排除するものではなく、その逆でもある。幾つかの手段を列挙する装置の請求項において、これら手段の幾つかは１つの同一のハードウェア品目により具現化することができる。また、特定の手段が相互に異なる従属請求書で引用されるという単なる事実は、これら手段の組み合わせを有利に使用することができないということを示すものではない。また、文章を通して"データ"及び"コンテンツ"なる用語が入れ替え可能に使用されているが、これらは均等のものであると理解されたい。
【図面の簡単な説明】
【０３５０】
【図１】図１は、タイムスタンプ付きトランスポートストリームパケットを示す。
【図２】図２は、イントラ符号化フレーム及び順方向予測フレームを伴うＭＰＥＧ２画像群（グループ・オブ・ピクチャ）構造を示す。
【図３】図３は、イントラ符号化フレーム、順方向予測フレーム及び双方向予測フレームを伴うＭＰＥＧ２画像群構造を示す。
【図４】図４は、特徴点情報ファイルの構造及び記憶されたストリームコンテンツを示す。
【図５】図５は、平文ストリームに対するトリックプレイのためのシステムを示す。
【図６】図６は、トリックプレイにおける時間圧縮を示す。
【図７】図７は、分数距離によるトリックプレイを示す。
【図８】図８は、低速トリックプレイを示す。
【図９】図９は、一般的な条件付きアクセスシステムの構造を示す。
【図１０】図１０は、デジタルビデオ放送の暗号化されたトランスポートストリームパケットを示す。
【図１１】図１１は、図１０のデジタルビデオ放送暗号化トランスポートストリームパケットのトランスポートストリームパケットヘッダを示す。
【図１２】図１２は、完全に暗号化されたストリームに対してトリックプレイの実行を可能にするシステムを示す。
【図１３】図１３は、完全なトランスポートストリーム及び部分的トランスポートストリームを示す。
【図１４】図１４は、ストリームタイプＩ用及びストリームタイプII用の権限制御メッセージ（ＥＣＭ：Entitlement Control Message）を示す。
【図１５】図１５は、解読器への制御ワードの書込を示す。
【図１６】図１６は、高速順送りモードでの権限制御メッセージの処理を示す。
【図１７】図１７は、１つ又は２つの制御ワードの検出を示す。
【図１８】図１８は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図１９】図１９は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２０】図２０は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２１】図２１は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２２】図２２は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２３】図２３は、本発明の一実施例によるデータストリームを処理する装置を示す。
【図２４】図２４は、本発明の一実施例によるデータストリームを処理する他の装置を示す。
【図２５】図２５は、フレーム境界でのパケットの分割を示す。
【図２６】図２６は、通常プレイデータの解読の後のスロー順送り構成を示す。
【図２７】図２７は、各フレーム境界に平文パケットを伴う複合ストリームを示す。
【図２８】図２８は、記憶された複合ストリームに対するスロー順送り構成を示す。
【図２９】図２９は、連結点における不完全な画像開始コードを示す。
【図３０】図３０は、通常プレイにおける再配列の効果を示す。
【図３１】図３１は、スロー順送りモードでの再配列の効果を示す。
【図３２】図３２は、アンカフレームの前の空のＰフレームの挿入を示す。
【図３３】図３３は、逆方向予測空Ｂフレームの使用を示す。
【図３４】図３４は、順方向予測空Ｂフレームの使用を示す。
【図３５】図３５は、フレーム当たり１ＰＥＳパケットの場合のストリームの分割を示す。
【図３６】図３６は、ＰＥＳヘッダの開始部におけるストリームの分割を示す。
【図３７】図３７は、画像開始コードの開始部におけるストリームの分割を示す。
【図３８】図３８は、画像開始コード内でのストリームの分割を示す。
【図３９】図３９は、連結点における不完全な画像開始コードを示す。
【図４０】図４０は、ｎ＋ｍ＝４の例を示す。
【図４１】図４１は、ｎ＋ｍ＞４の例を示す。
【図４２】図４２は、ｎ＋ｍ＜４の例を示す。
【図４３】図４３は、ＤＴＳまでの変更されない距離を示す。
【図４４】図４４は、一連の同一のＢフレームの境界における等しいオフセットを示す。
【図４５】図４５は、Ｂフレームデータ長を示す。
【図４６】図４６は、Ｂフレームが１フレーム時間より大きい場合のデータの重なりを示す。
【図４７】図４７は、一様に分散されたパケットによるＢフレームの圧縮を示す。
【図４８】図４８は、空のフレームの配置を示す。
【図４９】図４９は、空のフレームの最初のパケットの配置を示す。
【図５０】図５０は、前のフレームに基づく空のフレームのパケット距離を示す。
【図５１】図５１は、１フレーム期間にわたって一様に分散された空フレームのパケットを示す。
【図５２】図５２は、複合ストリームへの変換のための位置を示す。
【図５３】図５３は、完全に暗号化された記録からの安全なトリックプレイの生成を示す。
【図５４】図５４は、完全に平文の画像開始コードに対するバッファリングの必要性を示す。
【図５５】図５５は、Ｉフレームの開始部における実際の平文領域を示す。
【図５６】図５６は、実際の平文領域を示す。
【図５７】図５７は、２つのパケットにわたって広がる画像開始コードを示す。
【図５８】図５８は、部分的に暗号化された画像開始コードに付属された空のＰフレームを示す。
【図５９】図５９は、３つの基準に対応する平文データ領域を示す。
【図６０】図６０は、ＭＰＥＧ２におけるヘッダ構造を示す。
【図６１】図６１は、シーケンスの拡張及びシーケンスヘッダコードを示す。
【図６２】図６２は、画像符号化の拡張及び画像開始コードを示す。
【図６３】図６３は、２つのパケットにわたって広がるシーケンスヘッダコードを示す。
【技術分野】
【０００１】
本発明は、データストリームを処理する装置に関する。
【０００２】
また、本発明はデータストリームを処理する方法にも関する。
【０００３】
また、本発明はプログラムエレメントにも関する。
【０００４】
また、本発明はコンピュータ読み取り可能な媒体にも関する。
【背景技術】
【０００５】
電子娯楽（エンターテインメント）装置は、益々重要になってきている。特に、益々多くのユーザがハードディスク型オーディオ／ビデオプレーヤ及び他の娯楽装置を購入している。
【０００６】
記憶空間の低減はオーディオ／ビデオプレーヤの分野においては重要な問題であるので、オーディオ及びビデオデータは、しばしば、圧縮された態様で、及び保全的理由で暗号化された態様で記憶される。
【０００７】
ＭＰＥＧ２は、動画及び関連するオーディオの汎用的符号化のための規格であり、フレームデータからＧＯＰ（"グループ・オブ・ピクチャ"）構造と呼ばれる特定の順序で配列され得るビデオストリームを生成する。ＭＰＥＧ２ビデオのビットストリームは、画像を符号化する一連のデータフレームからなっている。画像を符号化する３つの方法は、イントラ符号化（Ｉ画像）、順方向予測（Ｐ画像）及び双方向予測（Ｂ画像）である。イントラ符号化されたフレーム（Ｉフレーム）は作りツリーに復号可能なフレームである。順方向予測フレーム（Ｐフレームは）、先行するＩフレーム又はＰフレームの情報を必要とする。双方向予測フレーム（Ｂフレーム）は先行する及び／又は後続のＩフレーム又はＰフレームの情報に依存する。
【０００８】
メディア再生装置においては、メディアコンテンツが通常速度で再生される通常再生モードから、メディアコンテンツが例えば低減された速度（"スロー順方向"）で、静止画像で又はその逆等の変更された態様で再生されるようなトリックプレイ再生モードへ切り換えることが興味ある機能である。
【０００９】
米国特許出願公開第２００５／０１５７７１４Ａ１号は、パケット型のスクランブルされたストリームを処理する方法であって、パケットストリームにおける複数のスクランブルされたパケットを受信するステップと、該スクランブルされたパケットの何れかをスクランブル解除するステップと、該スクランブル解除されたパケットの少なくとも１つと上記スクランブルされたパケットの少なくとも１つを含むような変更されたパケットストリームを送信するステップとを含むような方法を開示している。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、データストリームの効率的な処理を可能にすることにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、独立請求項によるデータストリームを処理する装置、データストリームを処理する方法、プログラムエレメント及びコンピュータ読み取り可能な媒体が提供される。
【００１２】
本発明の一実施例によれば、データストリームを処理する装置であって、隣接するフレーム間に解読されたフレーム境界部分を有するような部分的に解読された（及び部分的に暗号化された）データストリームの隣接するフレームを斯かるフレーム境界部分において分割する分割ユニットと、分割されたフレームを所定の複製レート（例えば、"３"等のトリックプレイ係数）に従って複数回複製する複製ユニットと、斯かる複製された分割されたフレームを接続する接続ユニットとを有するような装置が提供される。
【００１３】
本発明の他の実施例によれば、データストリームを処理する方法であって、隣接するフレーム間に解読されたフレーム境界部分を有するような部分的に解読された（及び部分的に暗号化された）データストリームの隣接するフレームを斯かるフレーム境界部分において分割するステップと、分割されたフレームを所定の複製レートに従って複数回複製するステップと、斯かる複製された分割されたフレームを接続するステップとを有するような方法が提供される。
【００１４】
更に、本発明の他の実施例によれば、コンピュータ読み取り可能な媒体であって、プロセッサにより実行された場合に上述した方法を制御又は実行するようなコンピュータプログラムが記憶された媒体が提供される。
【００１５】
更に、本発明の更に他の実施例によれば、プロセッサにより実行された場合に上述した方法を制御又は実行するようなプログラムエレメントが提供される。
【００１６】
本発明の実施例によるデータ処理は、コンピュータプログラムにより、即ちソフトウェアにより、又は１以上の特別な電子最適化回路を使用することにより、即ちハードウェアで、又は複合形態で、即ちソフトウェア構成要素及びハードウェア構成要素により実現することができる。
【００１７】
本発明の実施例による構成は、部分的に解読され且つ部分的に暗号化されたデータストリームを、異なるフレームが境界部分で分割され、後に斯かる分割されたフレームをスロー順送り又はスロー逆送り又は静止、より一般的にはスローモーション、トリックプレイ再生を可能にするような態様で再び接続することができるような形で処理することができるという利点を提供する。従って、隣接するフレーム間の平文部分は、どの位置で異なるフレームを切断すべきか、スローモーションのフィーチャを提供するために種々のフレームを複数回繰り返すべきか、及び適切な音声及び／又は画像が得られるように複製されたフレームシーケンスを一緒にすべきかの指示子として働くことができる。
【００１８】
一実施例によれば、フレーム分割アルゴリズム及び（分割及び複製された）フレームの接着が可能にされる。一実施例によるアルゴリズムによると、部分的に暗号化された"複合"スロー順送りＤＶＢ（"デジタルビデオ放送"）ストリームを、完全に暗号化された通常プレイ（例えば、ＭＰＥＧ）ストリームから発生することができる。このような手順は、トランスポートストリームのうちの画像フレーム境界を含む暗号化パケットのみを、スロー順送りを容易化するための対応する平文パケットにより選択的に置換するステップを含むことができる。更に、パケットを画像フレーム境界において分割することができ、スロー順送りストリームを、フレームを複製することにより発生することができる。画像フレーム境界におけるパケットは、必要ならば詰め込むことができる。次いで、画像開始コードが２つのパケットに跨る位置を識別することができ、これらに対して対応する補正を適用することができるが、該処理は接着と称することができる。
【００１９】
一実施例によれば、ＭＰＥＧ準拠デコーダに対するデジタルインターフェースを備えるようなＭＰＥＧトランスポートストリームを記憶するための記憶装置が設けられ、該デコーダは、暗号化されたＤＶＢストリームのスロー順送りプレイモードのためのＭＰＥＧ準拠ストリームを提供することができる。特別な筋書きにおいては、平文のスロー順送りストリームを解読及び生成する単純な処理は適切ではない可能性がある。何故なら、全情報が平文になるかもしれないからである。これは、保全の観点から望ましくないであろう。更に、家電装置におけるＤＶＢ暗号器の使用は許可されないであろう。この結果、処理は暗号化されたＤＶＢトランスポートストリームに対して実行されねばならないことになる。
【００２０】
かくして、本発明の一実施例によれば、複合（ハイブリッド）トランスポートストリームを使用することができ、該複合トランスポートストリームは、情報の主要部は暗号化されたままであることを保証しながら、スロー順送りＭＰＥＧ準拠トランスポートストリームの生成を可能にするために要する少量の（特には、最少量の）平文情報を有する。このような状況における１つの態様は、上記の暗号化されたトランスポートストリームにおける個々のフレームが、スロー順送りモードを提供するために繰り返されるというものである。この結果、特別なケースで、パケット境界を横切るＭＰＥＧ画像開始コードを補正するために前記フレームの分割及び後の個々のフレームの接着処理が要となる。この出願では、上記接着を実現する可能性が開示される。
【００２１】
かくして、本発明の実施例は、フレームを分離するためにパケットを分割するステップを含む。これは、Ｂフレームを繰り返すためにフレームを複製するステップ、及び元のＩ又はＰフレームを繰り返すために空のフレームを使用するオプションを含む。
【００２２】
更に、部分的に暗号化された開始コードで開始し、該暗号化された（暗号化されていない）パケットに存在する開始コードバイトの量を決定するアルゴリズムを実施することも可能である。結果として、パケットの接着が可能となる。パケットの連結の結果として、所定の閾値（例えば、４バイト）より大きな開始コードとなった場合、上記アルゴリズムは削除されるべきバイトの量を計算することができる。パケットの連結の結果として、所定の閾値（例えば、４バイト）より小さな開始コードとなった場合、追加の接着パケットを挿入することができる。
【００２３】
従って、本発明の一実施例は、パケットの分割及び接着につながるような、ストリームを暗号化するための画像開始コードの検出を目指す。
【００２４】
接着は、当該データストリームにおける上記開始コードの一部が存在する位置において実行することができ、追加のパケットを挿入するステップを含むことができる。詰め込みのために、特にはトランスポートストリームレベルの詰め込みのためにアダプテーションフィールド（ＡＦ）を挿入することができる。他の例として、例えば当該ストリームに１以上の単なる"ゼロ"を挿入することを含み、基本ストリームレベルの詰め込みも可能である。
【００２５】
当該データストリームのうちのデータストリーム処理を可能にするために解読される部分は、１％又はそれ以下の程度とすることができ、従って当該ストリームの９９％又はそれ以上は暗号化されたままとすることができる。
【００２６】
次に、本発明の他の実施例を説明する。
【００２７】
以下においては、データストリームを処理する装置の実施例を説明する。しかしながら、これら実施例は、データストリームを処理する方法、コンピュータ読み取り可能な媒体及びプログラムエレメントにも適用することができる。
【００２８】
当該装置は、（全体的に又は部分的に）暗号化されたデータストリームにおける隣接するフレーム間の暗号化されたフレーム境界部分を、解読されたフレーム境界部分により選択的に置換して部分的に解読されたデータストリームを形成する解読ユニットを有することができる。言い換えると、完全に暗号化されたデータストリームは、隣り合うフレーム間の暗号化された部分が対応する解読された部分により置換されるように処理されることが可能である。当該解読ユニットは、暗号化されたコンテンツを記憶する記憶装置（例えば、ハードディスク又はフラッシュメモリ）から分離して配置することができるか、又は斯様な記憶装置に統合することができる。また、斯様な記憶装置が既に部分的に解読された及び部分的に暗号化されたデータストリーム（これも、複合ストリームと称することができる）を記憶していることも可能である。
【００２９】
特には、上記解読ユニットは、暗号化されたデータストリームにおける隣接するフレーム間の暗号化されたフレーム境界部分のみを、解読されたフレーム境界部分により選択的に置換すると共に、全ての他のフレーム部分は暗号化されたままに維持するように構成することができる。従って、暗号化されたデータストリームのうちの必要な部分のみが解読され、これによりトリックプレイストリームの発生が、これらの平文部分に基づいて可能とされる。しかしながら、当該ストリームの部分（多くの場合には、主又は主要部分）が暗号化されたままとなり、かくして、高レベルの保全が達成される。
【００３０】
上記解読ユニットは、暗号化されたフレーム境界部分を解読されたフレーム境界部分により選択的に置換して、部分的に解読されたデータストリームを、小さな、好ましくは最少の量の解読された部分でトリックプレイストリームを発生するための基礎として形成するように構成することができる。この実施例によれば、略完全に暗号化されたデータストリームを、特にはスロー順送りストリーム又はスロー逆送りストリームであり得るような、スローモーションストリーム等のトリックプレイストリームを発生するために必要とされる部分のみが選択的に解読されたものと同時的に得ることが可能になる。
【００３１】
前記分割ユニットは、各分割フレームの開始部に平文パケットを挿入するように構成することができ、及び／又は分割パケットの詰め物をするように構成することができる。従って、異なるフレームを分割した後に、平文パケットを斯かる分割されたフレームの各々の終了部及び／又は開始部に挿入することができる。斯様なパケットは、対応するフレームを識別又は特徴付けるのに要する情報を含むことができるか、又は隣接するフレーム間の境界を単に詰めることができる。更に詳細には、分割は実際には挿入ではなく、分割パケットの詰め込み（先ず、前フレームの最終部分、次いで現フレームの最初の部分）である。これは、アダプテーションフィールドにより詰め込むこともできる。
【００３２】
このような平文パケットはヘッダ及び／又はアダプテーションフィールド（Adaptation Field: AF）を有することができる。アダプテーションフィールドなる用語は、ＭＰＥＧ符号化のフィールドから由来するものである。
【００３３】
前記接続ユニットは、複製された分割フレームを、フレーム境界部分（例えば、画像開始コード）が２つのフレームに跨っている場所を識別することに基づいて、及び斯様な識別された場所を訂正することに基づいて接続するように構成することができる。従って、スローモーショントリックプレイに従って複製分割フレームを一緒にする場合の如何なる可能性のある問題も、接着部分を調べることにより除去し又は取り除くことができる。これは、トリックプレイモードにおける再生の品質を改善させる。
【００３４】
前記接続ユニットは、特には、分割されたフレームのフレーム境界部分のサイズを決定すると共に、斯かる分割フレームを該決定されたサイズに基づいて接続するように構成することができる。上記サイズが過度に大きいと判断された場合（例えば４バイトなる閾値を超えた場合）、当該フレーム境界部分又は画像開始コードは対応して短縮され、所定の閾値に従うようにされる。他の場合において、当該フレーム境界部分のサイズが例えば４バイト等の所定の閾値より小さい場合、該サイズは、例えば当該フレーム境界部分に追加の部分を挿入することにより対応して増加される。このような対策を講じることにより、画像開始コードは所望の長さに調整することができ、これはシステム全体の制御性及び操作性を改善し得る。
【００３５】
当該装置は、データストリームを記憶する記憶ユニットを有することができる。このような記憶ユニットはハードディスク又はメモリカードとすることができ、これらは例えばオーディオ及び／又はビデオコンテンツを含むデータストリームを記憶することができる。
【００３６】
当該装置は、完全に暗号化されたデータストリームを処理するように構成することができる。言い換えると、全体のデータストリームは完全に暗号化され、従って許可されないアクセスに対して保全される。この場合、隣接するフレームの間の特別に規定された部分が、対応する平文部分により選択的に置換される。しかしながら、当該処理が実行されるストリームが部分的に又は完全に解読されることも本発明の範囲内である。
【００３７】
当該装置は、イントラ符号化フレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）及び双方向予測フレーム（Ｂフレーム）からなる群の少なくとも１つのフレームを処理するように構成することができる。ＭＰＥＧ２において、Ｉフレームは独立に復号可能なフレームである。Ｐフレームは先行するＩフレーム又はＰフレームの情報を必要とする。Ｂフレームは、先行する及び／又は後続のＩフレーム又はＰフレームの情報に依存する。
【００３８】
当該装置は、ビデオデータ及び／又はオーディオデータのデータストリームを処理するように構成することができる。しかしながら、このようなメディアコンテンツが、本発明の実施例による方式により処理することが可能な唯一のタイプのデータではない。トリックプレイの生成及び同様のアプリケーションは、ビデオ（オーディオビジュアル）データ処理及び（純）オーディオデータ処理の両方にとり課題であり得る。
【００３９】
当該装置は、更に、デジタルデータのデータストリームを処理するように構成することができる。
【００４０】
更に、当該装置は上記の処理されたデータストリームを再生又はプレイする再生ユニットを有することができ、該再生ユニットは前記接続ユニット（の出力端）に接続することができる。このような再生ユニットはスピーカ若しくはイヤホン若しくはヘッドフォン、及び／又はオーディオ及びビジュアルデータの両方を人が知覚できるように再生することができるような光学表示装置を有することができる。
【００４１】
更に、当該装置は前記データストリームをトリックプレイ再生モードで再生するように処理するための発生ユニットを有することができる。トリックプレイ再生モードで再生するためのデータストリームを発生するように構成された斯様なトリックプレイ発生ユニットは、ユーザにより、例えば装置の釦、キーパッド又はリモコン等のユーザインターフェースを介して対応するオプションを選択することにより調整することができる。ユーザにより選択されるトリックプレイ再生モードは、スローモーション再生モード（特には、スロー順送り又はスロー逆送り）、静止（stand still）モード、高速順方向再生モード、高速逆方向再生モード、静止フレーム（freeze frame）再生モード、瞬時リプレイ再生モード及び逆方向再生モードからなる群のうちの１つであり得る。しかしながら、他のトリックプレイストリームも可能である。トリックプレイ係数によるトリックプレイの場合、当該データのうちの一部のみを出力に使用することができるか（例えば、１より大きなトリックプレイ係数）、又は１つの同一のコンテンツを何回か再生することができる（例えば、１より小さなトリックプレイ係数）。
【００４２】
本発明の実施例による装置は、ＭＰＥＧ２データストリームを処理するように構成することができる。ＭＰＥＧ２はＭＰＥＧ（動画専門家グループ）により同意された一群のオーディオ及びビデオ符号化規格の名称であり、ＩＳＯ／ＩＥＣ１３８１８国際規格として公開されている。例えば、ＭＰＥＧ２はオーディオ及びビデオをデジタル衛星及びケーブルＴＶを含む放送信号用に符号化するために使用されるが、ＤＶＤにも使用することができる。
【００４３】
本発明の実施例による装置は、デジタルビデオ記録装置、ネットワーク可能化装置（network-enabled device）、条件付きアクセスシステム（限定受信システム：conditional access system）、携帯オーディオプレーヤ、携帯ビデオプレーヤ、携帯電話、ＤＶＤプレーヤ、ＣＤプレーヤ、ハードディスク型メディアプレーヤ、インターネットラジオ装置、公衆娯楽装置（public entertainment device）及びＭＰ３プレーヤからなる群のうちの１つとして実現することができる。しかしながら、これらのアプリケーションは例示に過ぎない。
【００４４】
本発明の上述した態様及び他の態様は、以下に述べる実施例から明らかであり、これら実施例を参照して説明される。
【発明を実施するための最良の形態】
【００４５】
以下、本発明を実施例に基づき詳細に説明する。
【００４６】
尚、各図は実寸ではなく概念的に示されたもので、異なる図における同一の符号は対応する構成要素を示している。また、当業者にとっては、本発明の他の等価な実施例が本発明の思想から逸脱することなしに可能であること、及び本発明の範囲が請求項によってのみ限定されるものであることは明であろう。
【００４７】
以下、図１ないし図１３を参照して、本発明の実施例によるトランスポートストリームに対する異なる態様のトリックプレイ構成を説明する。
【００４８】
特に、部分的に若しくは全体的に暗号化されているか又は暗号化されていないものとすることが可能なＭＰＥＧ２符号化ストリームに対しトリックプレイを実行するための幾つかの可能性を説明する。以下の説明は、ＭＰＥＧ２トランスポートストリームのフォーマットに固有な方法を目標としている。しかしながら、本発明は該フォーマットに限定されるものではない。
【００４９】
実験は、実際には、所謂タイムスタンプ付きトランスポートストリームという拡張で以って実施された。これは、トランスポートストリームパケットを有し、これらパケットの全てにはトランスポートストリームパケット到達時間が配置された４バイトのヘッダが前に付されている。この時間は、当該パケットの最初のバイトが記録装置で受信された時にプログラムクロック基準（ＰＣＲ）タイムベースの値から導出することができる。これは、ストリームに共にタイミング情報を記憶する好適な方法であり、従って該ストリームの再生は相対的に容易な処理となる。
【００５０】
再生の間における１つの課題は、ＭＰＥＧ２デコーダのバッファが超過する又はアンダフローしないことを保証することである。入力ストリームがデコーダバッファのモデルに準拠していたとしたならば、相対タイミングを復元することは、出力ストリームも準拠することを保証することになる。ここで説明するトリックプレイ方法の幾つかは、タイムスタンプとは独立であり、タイムスタンプを備える又は備えないトランスポートストリームに対して等しく良好に動作する。
【００５１】
図１は、タイムスタンプ付きトランスポートストリームパケット１００を示し、該パケットは１８８バイトの全長１０４を有すると共に、４バイトの長さ１０５を持つタイムスタンプ１０１、パケットヘッダ１０２及び１８４バイトの長さを持つパケットペイロード１０３を含んでいる。下記の説明は、記録されたトランスポートストリームからＭＰＥＧ／ＤＶＢ（デジタルビデオ放送）準拠のトリックプレイストリームを作成する可能性の概要を示すもので、完全に平文の、従ってデータの各ビットを操作することができるものから、完全に暗号化され（例えばＤＶＢ方式により）、従ってトランスポートストリームヘッダ及び幾つかのテーブルのみが操作のためにアクセス可能であり得るストリームまでの全スペクトルの記録ストリームをカバーすることを意図するものである。
【００５２】
ＭＰＥＧ／ＤＶＢトランスポートストリームに対するトリックプレイを作成する場合、コンテンツが少なくとも部分的に暗号化されていると問題が生じ得る。通常の方法であるように基本（エレメンタリ）ストリームレベルまで下降することは可能ではなく、又は解読の前に如何なるパケット化された基本ストリーム（ＰＥＳ）にアクセスすることさえ可能ではない。これは、画像フレームを見つけることが不可能であることをも意味する。既知のトリックプレイエンジンは、この情報をアクセス及び処理することができる必要がある。
【００５３】
この説明の枠内では、"ＥＣＭ"なる用語は権限制御メッセージ（Entitlement Control Message）を指す。このメッセージは、特に、秘密のプロバイダ所有権情報を有し得、とりわけ、ＭＰＥＧストリームを解読するのに要する暗号化された制御ワード（ＣＷ）を含み得る。典型的には、制御ワードは１０〜２０秒内で終了する。ＥＣＭはトランスポートストリーム内のパケットに埋め込まれている。
【００５４】
この説明の枠内において、"キー"なる用語は、特に、スマートカードに記憶することが可能であると共に、トランスポートストリーム内に埋め込まれ得る所謂"権限管理メッセージ（Entitlement Management Message）"即ちＥＭＭを用いて該スマートカードに転送することが可能なデータを指す。これらのキーは、スマートカードによりＥＣＭ内に存在する制御ワードを解読するために使用することができる。斯様なキーの例示的有効期間は１ヶ月である。
【００５５】
この説明の枠内において、"制御ワード（ＣＷ）"なる用語は、特に、実際のコンテンツを解読するために要する解読情報を指す。制御ワードはスマートカードにより解読され、次いで解読コアのメモリに記憶することができる。
【００５６】
ここで、平文ストリームに対するトリックプレイに関する幾つかの態様を説明する。
【００５７】
作成された如何なるＭＰＥＧ２ストリームも、ＭＰＥＧ２準拠のトランスポートストリームであることが好ましい。これは、デコーダを装置内に統合することができるのみならず、例えばIEEE 1394インターフェース等の標準のデジタルインターフェースを介して接続することができるからである。
【００５８】
高圧縮比を達成するためにビデオの時間的冗長性を利用するＭＰＥＧ２等のビデオ符号化技術を使用する場合に発生し得る如何なる問題も考慮されるべきである。フレームは、最早、独立に復号することはできない。複数の画像群（ＧＯＰ）の構造が図２に示されている。図２は、特に、Ｉフレーム２０１及びＰフレーム２０２のシーケンスを伴う幾つかのＭＰＥＧ２のＧＯＰ構造を有するストリーム２００を示している。ＧＯＰのサイズが符号２０３により示されている。該ＧＯＰのサイズ２０３は１２フレームに設定され、ここでは、Ｉフレーム２０１及びＰフレーム２０２のみが示されている。
【００５９】
ＭＰＥＧにおいては、最初のフレームのみが他のフレームとは独立に符号化されているようなＧＯＰ構造を使用することができる。これは、所謂イントラ符号化された、即ちＩフレーム２０１である。予測フレーム即ちＰフレーム２０２は単方向予測により符号化され、図２において矢印２０４により示されるように、これらフレームは前のＩフレーム２０１又はＰフレーム２０２にのみ依存することを意味する。このようなＧＯＰ構造は、典型的には、１２又は１６個のサイズのフレーム２０１、２０２を有する。複数のＧＯＰの他の構造３００が図３に示されている。図３は、特に、Ｉフレーム２０１、Ｐフレーム２０２及びＢフレーム３０１のシーケンスを伴うＭＰＥＧ２のＧＯＰ構造を示す。該ＧＯＰのサイズも、符号２０３で示す。
【００６０】
図３に示すように、双方向予測フレーム即ちＢフレーム３０１も含むＧＯＰ構造を使用することができる。例として、１２フレームのサイズのＧＯＰが選択されている。Ｂフレーム３０１は双方向予測により符号化され、これらフレームが、幾つかのＢフレーム３０１に関して湾曲した矢印２０４により示されているように、前の及び次のＩ又はＰフレーム２０１、２０２に依存することを意味する。圧縮されたフレームの伝送順序は、これらが表示される順序とは同一とは限らない。
【００６１】
Ｂフレーム３０１を復号するためには、当該Ｂフレームの（表示順での）前及び後の両基準フレームが必要とされる。デコーダにおけるバッファの必要条件を最少にするために、圧縮されたフレームは再配列することができる。従って、伝送において、基準フレームは最初にくることができる。送信されたままで再配列されたストリームも、図３の下側に示されている。再配列は、真っ直ぐな矢印３０２により示されている。Ｂフレーム３０１を含むストリームは、全てのＢフレーム３０１がスキップされたなら（跳ばされたなら）良い見え方のトリックプレイ画像となり得る。本例の場合、これは３倍順送りトリックプレイ速度となる。
【００６２】
ＭＰＥＧ２ストリームが暗号化されていなくても（即ち、平文であっても）、トリックプレイは些細なことではない。Ｉフレームのみに基づくスロー逆送りの可能性を短く説明する。ＭＰＥＧ２のＧＯＰの必要な反転のために、効率的なフレームに基づくスロー逆送りは一層困難である。スローモーション順送りとしても知られているスロー順送りは、表示画像が通常速度よりも低い速度で進むようなモードである。スロー順送りの基本的形態は、トリックプレイＧＯＰを発生する高速順送りアルゴリズムを利用する技術を用いて既に可能である。高速順送り速度をゼロと１との間の値に設定する結果として、高速順送りトリックプレイＧＯＰの繰り返しに基づくスロー順送りストリームが得られる。平文ストリームの場合、これは問題とならないが、暗号化されたストリームの場合、これは或る特定の条件ではＩフレームの一部の誤った解読につながり得る。この問題を解決する幾つかのオプションが存在するが、最も適切な方法は、高速順送りトリックプレイＧＯＰを繰り返すのではなく、空のＰフレームの追加により該トリックプレイＧＯＰのサイズを延長することである。この技術は、実際に、スロー逆送りも可能にする。何故なら、高速順送り／逆送りに使用されるトリックプレイＧＯＰに、従って独立に復号可能なＩフレームに基づいているからである。しかしながら、以下のような理由により、この種のＩフレームに基づくスロー順送り又はスロー逆送りを利用することは好ましくない。通常プレイにおけるＩフレーム間の距離は約半秒であり、これは、スロー順送り又は逆送りの場合、スローモーション係数で乗算される。従って、このタイプのスロー順送り／逆送りは、現実にはユーザが馴れているスローモーションではなく、実際には連続する画像の間に大きな時間的距離を伴うスライドショーのようなものである。
【００６３】
静止画モードと呼ばれる他のトリックプレイモードでは、表示画像は停止される。これは、静止画モードの間にわたり当該Ｉフレームに空Ｐフレームを追加することにより達成することができる。これは、最後のＩフレームからの結果の画像が停止されることを意味する。通常プレイから静止画に切り換える場合、これは、ＣＰＩファイル内のデータによる最も近いＩフレームでもあり得る。この技術は、高速順送り／逆送りモードの拡張であり、インターレース除去が使用された場合、良好な静止画像が得られる。しかしながら、通常プレイ又はスロー順送り／逆送りから静止画に切り換える場合、位置的精度が時には十分ではない。
【００６４】
静止画モードはステップモードを実施化するために拡張することができる。ステップコマンドは、当該ストリームを何れかの次の又は前のＩフレームに進める。ステップサイズは、最小で１ＧＯＰであるが、ＧＯＰの整数に等しいような大きな値に設定することもできる。この場合、ステップ順送り及びステップ逆送りの両方とも可能である。何故なら、Ｉフレームのみが使用されるからである。
【００６５】
スロー順送りは、各フレームの繰り返しに基づくものとすることもでき、これは一層滑らかなスローモーションとなる。スロー順送りの最良の形態は、実際には、フレームの代わりにフィールドの繰り返しであろう。何故なら、時間解像度が倍となり、インターレースアーチファクトが存在しないからである。しかしながら、これは本来的にフレームに基づくＭＰＥＧ２ストリームに対しては事実上不可能であり、大幅に暗号化されている場合は一層そうである。インターレースアーチファクトは、Ｉ及びＰフレームに関しては、繰り返しを強制するための特別な空のフレームを用いることにより大幅に低減することができる。もっとも、このようなインターレース低減技術は、Ｂフレームに対しては利用可能ではない。Ｉ及びＰフレームに対するインターレース除去の使用が、この場合において依然として有利であるか、又は視聴者にとり実際に一層不快な画像となるかは実験によってのみ検証し得る。
【００６６】
時間的予測故に、個々のフレームに基づくスロー逆送りはＭＰＥＧ信号にとっては実際には非常に複雑となる。完全なＧＯＰが、バッファリングされ、且つ、反転されねばならない。知り得る限り、ＧＯＰにおけるフレームを逆の順序に再符号化する簡単な方法は存在しない。従って、略完全な復号及び符号化が、これら２つの間におけるフレーム順序の反転と共に必要となる。これは、完全な復号されたＧＯＰのバッファリング並びにＭＰＥＧデコーダ及びエンコーダを必要とする。
【００６７】
静止画モードは、フレームに基づくスロー順送りモードの拡張と定義することができる。これは、当該フレームのタイプが何であれ、静止画モードの期間にわたる現フレームの繰り返し表示に基づくものである。これは、スローモーション係数が、通常プレイストリームが低速化される係数を示すものであるならば、実際には無限のスローモーション係数によるスロー順送りである。Ｂフレームで画像が停止された場合、インターレース除去は可能ではない。その意味では、この静止画モードは、トリックプレイＧＯＰに基づく静止画モードより悪い。これは、幾らか静止画の位置の精度が劣ることを犠牲にして、Ｉ又はＰフレームで画像を停止させることによってのみ訂正することができる。この場合、ＰＴＳ及び時間基準の不連続も回避することができる。更に、ビットレートも大幅に低減される。何故なら、Ｂフレームに対して必要とされるようにフレームデータ自体の繰り返しの代わりに、空のフレームの挿入によりＩ又はＰフレームの繰り返しが強制されるからである。従って、技術的に言って、Ｉ又はＰフレームにおける画像の停止は最良の選択である。
【００６８】
上記静止画モードは、ステップモードで拡張することもできる。ステップコマンドは、当該ストリームを基本的に次のフレームに進める。次のＰフレーム又は何れかの次のＩフレームへのステップ動作により大きなステップサイズが可能となる。フレームに基づくステップ逆送りは可能ではない。唯一のオプションは、前のＩフレームのうちの１つへのステップ逆送りである。
【００６９】
以上、２つのタイプの静止画モード、即ちトリックプレイＧＯＰに基づくもの及びフレームに基づくものに言及した。最初のものは高速順送り／逆送りに略論理的に関連する一方、２番目のものはスロー順送りに関係している。何らかのモードから静止画に切り換える場合、切り換え遅れを最小にするために、関係する静止画モードを選択することが好ましい。両方法から得られるストリームは非常に似ている。何故なら、これらは共に、アンカフレームの繰り返しを強制するための空フレームの挿入に基づいているからである。しかしながら、詳細なストリーム構成レベルでは、幾つかの差が存在する。
【００７０】
以下においては、ＣＰＩ（"特徴点情報"）ファイルに関係する幾つかの態様を説明する。
【００７１】
ストリーム内のＩフレームを見つける処理は、通常は、フレームヘッダを見つけるために当該ストリームの解析を必要とする。Ｉフレームが開始する位置を突き止めることは、記録がなされている間に、又は記録が完了した後にオフラインで、又は半オンライで、実際にはオフラインであるが記録の時点に対して小さな遅延で、実施することができる。Ｉフレームの終了部は、次のＰフレーム又はＢフレームの開始を検出することにより見つけることができる。このようにして導出されたメタデータは、特徴点情報ファイル又はＣＰＩファイルと称することが可能な別個ではあるが結合されたファイルに記憶することができる。このファイルは、トランスポートストリームファイルにおける各Ｉフレームの開始部及び結果的に終了部に対するポインタを含むことができる。個々の記録は、自身のＣＰＩファイルを有することができる。
【００７２】
特徴点情報ファイル４００の構造が図４に示されている。
【００７３】
ＣＰＩファイル４００とは別に、記憶された情報４００も示されている。ＣＰＩファイル４００は、ここでは説明しない幾つかの他のデータも含むことができる。
【００７４】
ＣＰＩファイル４００からのデータにより、当該ストリームにおける如何なるＩフレーム２０１の開始部へのジャンプも可能となる。該ＣＰＩファイル４００がＩフレーム２０１の終了部も含んでいる場合、完全なＩフレーム２０１を得るために、当該トランスポートストリームファイルから読み取るべきデータの量も正確にわかる。何らかの理由により当該Ｉフレームの終了部がわからない場合、全体のＩフレーム２０１が読み取られることを確実にするために、全体のＧＯＰ又は当該ＧＯＰデータの少なくとも大部分が読み取られねばならない。当該ＧＯＰの終了部は、次のＩフレーム２０１の開始部により与えられる。測定から、Ｉフレームデータの量は全ＧＯＰデータの４０％以上であり得ることがわかる。
【００７５】
トリックプレイの画像リフレッシュレートの低減は各Ｉフレーム２０１を数回表示することにより達成することができることが知られている。それに応じてビットレートが低減される。これは、Ｉフレーム２０１の間に所謂空Ｐフレーム２０２を追加することにより達成することができる。このような空Ｐフレーム２０２は、実際には空ではなく、当該デコーダに前のフレームを繰り返すように命令するデータを含むことができる。これは限られたビットの犠牲しか有さず、多くの場合、Ｉフレームと比較して無視することができる。実験から、ＩＰＰ又はＩＰＰＰ等のトリックプレイＧＯＰ構造は、トリックプレイの画像品質にとって許容することができ、高いトリックプレイ速度では有利でさえあり得ることが知られている。結果としてのトリックプレイのビットレートは、通常プレイのビットレートのものと同程度である。これらの構造が記憶装置からの必要とされる持続帯域幅を低減し得ることも言及されている。
【００７６】
ここで、タイミングの問題及びストリーム構造に関する幾つかの態様を説明する。
【００７７】
トリックプレイシステム５００が図５に概念的に示されている。
【００７８】
トリックプレイシステム５００は、記録ユニット５０１と、Ｉフレーム選択ユニット５０２と、トリックプレイ発生ブロック５０３と、ＭＰＥＧ２デコーダ５０４とを有している。トリックプレイ発生ブロック５０３は、解析ユニット５０５と、加算ユニット５０６と、パケタイザユニット５０７と、テーブルメモリユニット５０８と、マルチプレクサ５０９とを含んでいる。
【００７９】
記録ユニット５０１は、Ｉフレーム選択ユニット５０２に平文ＭＰＥＧ２データ５０１を供給する。マルチプレクサ５０９はＭＰＥＧ２デコーダ５０４にＭＰＥＧ２ ＤＶＢ準拠のトランスポートストリーム５１１を供給する。
【００８０】
Ｉフレーム選択器５０２は、記憶装置５０１から特定のＩフレーム２０１を読み取る。どのＩフレーム２０１が選択されるかは、以下に説明するようにトリックプレイ速度に依存する。取り出されたＩフレーム２０１はＭＰＥＧ２／ＤＶＢ準拠のトリックプレイストリームを構築するために使用され、該ストリームは次いで復号及びレンダリングのためにＭＰＥＧ２デコーダ５０４に送られる。
【００８１】
上記トリックプレイストリームにおけるＩフレームパケットの位置は、元のトランスポートストリームの相対タイミングと結びつけることはできない。トリックプレイにおいては、時間軸は速度係数により圧縮又は伸張され得、更に逆送りトリックプレイのために反転され得る。従って、元のタイムスタンプ付けされたトランスポートストリームのタイムスタンプはトリックプレイの発生には適さないであろう。
【００８２】
更に、元のＰＣＲタイムベースはトリックプレイに対して妨害的となり得る。先ず、ＰＣＲが、選択されたＩフレーム２０１内で利用可能であることは保証されない。しかしながら、もっと重要なことは、ＰＣＲタイムベースの周波数が変化されることであろう。ＭＰＥＧ２仕様によれば、この周波数は２７ＭＨｚから３０ｐｐｍ内でなければならない。元のＰＣＲタイムベースは、この要件を満たすが、トリックプレイに使用された場合、トリックプレイ速度係数により乗算されるであろう。逆送りトリックプレイの場合、これは間違った方向に走るタイムベースとさえなる。従って、古いタイムベースは削除されねばならず、あらたしいものがトリックプレイストリームに追加されねばならない。
【００８３】
最後に、Ｉフレーム２０１は、通常、デコーダ５０４に対し何時当該フレーム開始すべきか（復号タイムスタンプ、ＤＴＳ）及び該フレームを何時提示（例えば表示）開始すべきか（提示タイムスタンプ、ＰＴＳ）を告げる２つのタイムスタンプを含んでいる。復号及び提示は、ＤＴＳ及びＰＴＳが、デコーダ５０４内で当該ストリームにおけるＰＣＲにより再生されたＰＣＲタイムベースに等しい場合に開始することができる。例えば２つのＩフレーム２０１のＰＣＲ値の間の距離は、それらの表示時間の通常の距離に対応する。トリックプレイにおいては、この時間距離は速度係数により圧縮又は伸張される。トリックプレイにおいては新たなＰＣＲタイムベースが使用され、ＤＴＳ及びＰＴＳに関する距離は、最早、正しくないので、Ｉフレーム２０１の元のＤＴＳ及びＰＴＳは置換されねばならない。
【００８４】
上述した複雑さを解決するために、Ｉフレーム２０１は先ず解析ユニット５０５において基本ストリーム（エレメンタリストリーム）に分解することができる。次いで、基本ストリームレベルにおいて空のＰフレーム２０２が追加される。得られたトリックプレイＧＯＰは１つのＰＥＳパケットにマッピングされ、トランスポートストリームパケットにパケット化される。次いで、ＰＡＴ、ＰＭＴ等の補正されたテーブルが追加される。この段階において、新しいＰＣＲタイムベースがＤＴＳ及びＰＴＳと一緒に含まれる。トランスポートストリームパケットには、当該トリックプレイストリームが通常プレイに使用されるのと同一の出力回路により処理され得るように、ＰＣＲタイムベースに結合された４バイトのタイプストリームが前に添付される。
【００８５】
以下においては、トリックプレイ速度に関連する幾つかの態様を説明する。この状況において、先ず、固定のトリックプレイ速度を説明する。
【００８６】
前述したように、Ｉフレーム２０１に２つの空のＰフレーム２０２が後続するようなＩＰＰ等のトリックプレイＧＯＰ構造を使用することができる。元のＧＯＰは１２フレームのＧＯＰサイズ２０３を有し、元の全てのＩフレーム２０１がトリックプレイに使用されると仮定する。これは、通常プレイストリームにおけるＩフレーム２０１は１２フレームの距離を有し、トリックプレイストリームにおける同じＩフレーム２０１は３フレームの距離を有することを意味する。これは、１２／３＝４なるトリックプレイ速度となる。元のＧＯＰのフレームでのサイズ２０３がＧにより、トリックプレイＧＯＰのフレームでのサイズがＴにより、トリックプレイ速度係数がＮｂにより各々示された場合、一般的にトリックプレイ速度は、
Ｎｂ＝Ｇ／Ｔ （１）
により与えられる。
【００８７】
Ｎｂは基本速度とも呼ばれる。一層早い速度は、元のストリームからＩフレーム２０１をスキップすることにより実現することができる。２つ目毎のＩフレーム２０１がとられた場合、トリックプレイ速度は倍となり、３つ目毎のフレームがとられた場合、トリックプレイ速度は３倍となり、等々となる。言い換えると、元のストリームにおける使用されるＩフレーム２０１の間の距離は２、３等となる。この距離は常に整数であり得る。トリックプレイの発生に使用されるＩフレーム２０１の間の距離がＤにより示される場合（Ｄ＝１は全Ｉフレーム２０１が使用されることを意味する）、一般的トリックプレイ速度係数Ｎは、
Ｎ＝Ｄ＊Ｇ／Ｔ （２）
により与えられる。
【００８８】
これは、基本速度の全ての整数倍を実現することができ、許容可能な速度の組となることを意味する。逆送りトリックプレイに対してはＤが負となり、Ｄ＝０は静止画となることに注意されたい。データは順方向においてのみ読み取ることができる。従って、逆送りトリックプレイにおいては、データは順方向に読み取られ、Ｄにより与えられる先行するＩフレーム２０１を取り出すために逆方向へのジャンプがなされる。大きなトリックプレイＧＯＰサイズＴが一層遅い基本速度になることにも注意されたい。例えば、ＩＰＰＰはＩＰＰよりも一層細かな粒度の速度組になる。
【００８９】
図６を参照して、トリックプレイにおける時間圧縮を説明する。
【００９０】
図６は、Ｔ＝３（ＩＰＰ）及びＧ＝１２の状況を示している。Ｄ＝２の場合、２４フレームの元の表示時間は、３フレームのトリックプレイ表示時間に圧縮され、結果としてＮ＝８となる。与えられた例において、基本速度は整数であるが、これが必ずしも当てはまるわけではない。Ｇ＝１６及びＴ＝３の場合、基本速度は１６／３＝５及び１／３となり、これは整数トリックプレイ速度の組とはならない。従って、１６なるＧＯＰサイズに対してはＩＰＰＰ構造（Ｔ＝４）の方が一層適しており、結果として４ｘなる基本速度となる。１２及び１６なる最も普通のＧＯＰサイズに適合する単一のトリックプレイ構造が望ましい場合、ＩＰＰＰを選択することができる。
【００９１】
次に、任意のトリックプレイ速度を説明する。
【００９２】
幾つかの場合においては上述した方法から得られるトリックプレイ速度の組が満足のいくものとなるが、幾つかの場合においてはそうではない。Ｇ＝１６及びＴ＝３の場合、依然として整数のトリックプレイ速度係数を好む場合もあり得る。Ｇ＝１２及びＴ＝４の場合でさえ、例えば７ｘ等の当該組においては利用可能でない速度を有することが好まれ得る。ここで、前記トリックプレイ速度方程式が反転され、距離Ｄが計算されるが、これは、
Ｄ＝Ｎ＊Ｔ／Ｇ （３）
により与えられる。
【００９３】
Ｇ＝１２、Ｔ＝４及びＮ＝７なる上記例を用いると、Ｄ＝２ １／３となる。固定数のＩフレーム２０１をスキップする代わりに、次のＩフレーム２０１を何のＩフレーム２０１が所要の速度に最良に適合するかの事実に基づいて選択するような適応的スキップアルゴリズムを使用することができる。最良に適合するＩフレーム２０１を選択するために、距離Ｄを持つ次の理想点Ｉｐを計算することができ、Ｉフレーム２０１のうちの、この理想点に最も近い１つを選択して、トリックプレイＧＯＰを構築することができる。続くステップにおいては、最後の理想点をＤだけ増加させることにより、次の理想点を再び計算することができる。
【００９４】
断片的距離でトリックプレイを図示する図７に示されるように、特にＩフレーム２０１を選択する３つの可能性が存在する。即ち、
Ａ．理想点に最も近いＩフレーム；Ｉ＝round(Ip)
Ｂ．理想点より前の最後のＩフレーム；Ｉ＝int(Ip)
Ｃ．理想点より後の最初のＩフレーム；Ｉ＝int(Ip)+1
である。
【００９５】
明らかにわかるように、実際の距離はint(D)とint(D)+1との間で変化し、２つの発生の間の比は、平均距離がＤに等しくなるようにＤの分数に依存する。これは、平均トリックプレイ速度はＮに等しいが、実際に使用されるフレームは理想のフレームに対して小さなジッタを有することを意味する。これに関して幾つかの実験が実行されたところ、トリックプレイ速度は局部的に変化し得るが、これは視覚的に乱すものではない。普通には、特に幾らか高いトリックプレイ速度では目立つことさえない。図７からは、方法Ａ、Ｂ又はＣの何れを選んでも本質的な差はないことも明らかである。
【００９６】
この方法によれば、トリックプレイ速度Ｎは整数である必要はなく、基本速度Ｎｂより大きな如何なる値とすることもできる。この最小値より低い速度も選択することができるが、その場合、画像リフレッシュレートが局部的に低下され得る。何故なら、実効的トリックプレイＧＯＰサイズが倍になるか、更に低い速度では３倍又はそれ以上になるからである。これはトリックプレイＧＯＰの繰り返しによる。というのは、当該アルゴリズムが同一のＩフレーム２０１を２回以上選択するからである。
【００９７】
図８は、Ｎ＝２／３・Ｎｂと等価のＤ＝２／３の例を示している。ここでは、Ｉフレーム２０１を選択するために丸め関数が使用され、見られるように、フレーム２及び４が２回選択される。
【００９８】
何れにしろ、上述した方法は連続的に変化可能なトリックプレイ速度を可能にする。逆送りトリックプレイの場合、Ｎに対して負の値が選択される。図７の例の場合、これは、単に矢印７００が逆の方向を指すことを意味する。上述した方法は、先に言及した固定のトリックプレイ速度の組も含み、これらは、特に丸め関数が使用された場合、同じ品質を有するであろう。従って、この節で述べた柔軟な方法は速度の選択がどの様であれ常に実施化されるべきであることが適切であろう。
【００９９】
ここで、トリックプレイ画像のリフレッシュレートに関する幾つかの態様を説明する。
【０１００】
"リフレッシュレート"なる用語は、特に、新しい画像が表示される周波数を指す。速度依存的ではないが、Ｔの選択に影響を与え得るので、ここでは簡単に述べる。元の画像のリフレッシュレートがＲ（２５Ｈｚ又は３０Ｈｚ）により示される場合、トリックプレイ画像のリフレッシュレート（Ｒｔ）は、
Ｒｔ＝Ｒ／Ｔ （４）
により与えられる。
【０１０１】
ＩＰＰ（Ｔ＝３）又はＩＰＰＰ（Ｔ＝４）のトリックプレイＧＯＰ構造によれば、リフレッシュレートＲｔは、ヨーロッパでは各々８1/3Ｈｚ又は６1/4Ｈｚとなり、米国では各々１０Ｈｚ又は７1/2Ｈｚとなる。トリックプレイ画像の品質の判定は幾らかは主観的事項であるが、実験から、これらリフレッシュレートは低い速度では許容可能であり、高い速度では更に有利であるとの明らかな手がかりが存在する。
【０１０２】
以下においては、暗号化されたストリーム環境に関する幾つかの態様を説明する。
【０１０３】
ここで、暗号化されたストリーム上でのトリックプレイの説明のための基礎として、暗号化されたトランスポートストリームについての幾らかの情報を示す。放送用に使用される条件付きアクセスシステム（Conditional Access System）に焦点を合わせる。
【０１０４】
図９は、ここで説明する条件付きアクセスシステム９００を示す。
【０１０５】
該条件付きアクセスシステム９００において、コンテンツ９０１はコンテンツ暗号化ユニット９０２に供給することができる。コンテンツ９０１を暗号化した後、コンテンツ暗号化ユニット９０２はコンテンツ解読ユニット９０４に暗号化されたコンテンツ９０３を供給する。この明細書において、ＥＣＭは権限制御メッセージ（Entitlement Control Message）を指すと述べた。更に、ＫＭＭはキー管理メッセージ（Key Management Message）を指し、ＧＫＭはグループキーメッセージ（Group Key Message）を指し、ＥＭＭは権限管理メッセージ（Entitlement Management Message）を指すものとする。制御ワード９０６をコンテンツ暗号化ユニット９０２及びＥＣＭ発生ユニット９０７に供給することができる。ＥＣＭ発生ユニット９０７はＥＣＭを発生し、同ＥＣＭをスマートカード９０５のＥＣＭ復号ユニット９０８に供給する。ＥＣＭ復号ユニット９０８は上記ＥＣＭから制御ワードを発生し、該制御ワードは暗号化されたコンテンツ９０３を解読するために必要とされる解読情報で、コンテンツ解読ユニット９０４に供給される。
【０１０６】
更に、許可キー（authorization key）９１０がＥＣＭ発生ユニット９０７及びＫＭＭ発生ユニット９１１に供給され、その場合において、後者はＫＭＭを発生し、同ＫＭＭをスマートカード９０５のＫＭＭ復号ユニット９１２に供給する。ＫＭＭ復号ユニット９１２は出力信号をＥＣＭ復号ユニット９０８に供給する。
【０１０７】
更に、グループキー９１４をＫＭＭ発生ユニット９１１及びＧＫＭ発生ユニット９１５に供給することができ、ＧＫＭ発生ユニット９１５には更にユーザキー９１８を供給することができる。ＧＫＭ発生ユニット９１５はＧＫＭ信号ＧＫＭを発生すると共に、同ＧＫＭ信号をスマートカード９０５のＧＫＭ復号ユニット９１６に供給し、該ＧＫＭ復号ユニット９１６は更なる入力としてユーザキー９１７を得る。
【０１０８】
更に、エンタイトルメント（権限）９１９をＥＭＭ発生ユニット９２０に供給することができ、該ＥＭＭ発生ユニットはＥＭＭ信号を発生すると共に同信号をＥＭＭ復号ユーザ９２１に供給する。スマートカード９０５内に位置する上記ＥＭＭ復号ユニット９２１は権限リストユニット９１３に結合されており、該権限リストユニットはＥＣＭ復号ユニット９０８に対応する制御情報を供給する。
【０１０９】
多くの場合において、コンテンツプロバイダ及びサービスプロバイダは、条件付きアクセス（ＣＡ）システムを介して、特定のコンテンツ項目へのアクセスを制御したいと欲する。
【０１１０】
これを達成するために、放送されるコンテンツ９０１はＣＡシステム９００の制御の下で暗号化される。受信機において、コンテンツは、ＣＡシステム９００によりアクセスが許可されたなら、復号及びレンダリングする前に解読される。
【０１１１】
ＣＡシステム９００は層状の階層構造を使用する（図９参照）。ＣＡシステム９００はコンテンツ解読キー（制御ワードＣＷ９０６，９０９）をサーバからクライアントへＥＣＭと呼ばれる暗号化されたメッセージの形態で転送する。ＥＣＭは許可キー（ＡＫ）９１０を使用して暗号化されている。安全保護の理由で、ＣＡサーバ９００は許可キー９１０を、ＫＭＭを発行することにより更新する。実際には、ＫＭＭは特別なタイプのＥＭＭであるが、明瞭化のために、ＫＭＭなる用語を使用する。ＫＭＭも、例えばグループキー（ＧＫ）９１４とすることが可能なキーを用いて暗号化されており、該グループキーは、これも特別なタイプのＥＭＭであるＧＫＭを送ることにより更新される。この場合、ＧＫＭはユーザキー（ＵＫ）９１７，９１８により暗号化され、該ユーザキーはスマートカード９０５に埋め込まれ、当該プロバイダのＣＡシステム９００によってのみ知られた固定の固有のキーである。許可キー及びグループキーは、受信機のスマートカード９０５内に記憶される。
【０１１２】
エンタイトルメント９１９（例えば、視聴権）は、個々の顧客にＥＭＭの形態で送信され、安全保護装置（スマートカード９０５）にローカルに記憶される。エンタイトルメント９１９は特定の番組（プログラム）に結合される。権限リスト９１３は、契約のタイプに応じて一群の番組に対するアクセスを与える。ＥＣＭは、エンタイトルメント９１９が特定の番組に対して利用可能である場合にのみ、スマートカード９０５によりキー（制御ワード）へと処理される。エンタイトルメントＥＭＭは、ＫＭＭと同じ層状構造に従う（図９には示されていない）。
【０１１３】
ＭＰＥＧ２システムにおいては、暗号化されたコンテンツＥＣＭ及びＥＭＭ（ＫＭＭ及びＧＫＭタイプを含む）は、全て単一のＭＰＥＧ２トランスポートストリームに多重化される。上述した説明は、ＣＡシステム９００の概要である。デジタルビデオ放送においては、暗号化アルゴリズム、奇数／偶数制御ワード構造、ＥＣＭ及びＥＭＭの全体構造並びにそれらの参照が規定される。ＣＡシステム９００の詳細な構造並びにＥＣＭ及びＥＭＭのペイロードが符号化及び使用される方法は、プロバイダに固有のものである。また、スマートカードもプロバイダ固有である。しかしながら、経験から、多くのプロバイダが図９の概要図のような構造に本質的に従っていることが分かっている。
【０１１４】
以下においては、ＤＶＢ暗号化／解読の主たる題目を説明する。
【０１１５】
適用される暗号化及び解読アルゴリズムは、ＤＶＢ標準化組織により規定される。原則的に、２つの暗号化の可能性、即ちＰＥＳレベル暗号化及びＴＳレベル暗号化が規定される。しかしながら、実世界では、主にＴＳレベル暗号化が使用されている。トランスポートストリームパケットの暗号化及び解読は、パケットに基づいてなされる。これは、暗号化及び解読アルゴリズムが、新たなトランスポートストリームパケットが受信される毎に再開されることを意味する。従って、パケットは個別に暗号化又は解読することができる。トランスポートストリームにおいては、暗号化された及び平文のパケットが混合されている。何故なら、幾つかのストリーム部分は暗号化され（例えば、オーディオ／ビデオ）、他のものは暗号化されない（例えば、テーブル）からである。１つのストリーム部分（例えば、ビデオ）内でさえ、暗号化された及び平文のパケットが混合され得る。
【０１１６】
図１０を参照して、ＤＶＢ暗号化トランスポートストリームパケット１０００を説明する。
【０１１７】
ストリームパケット１０００は、１８８バイトの長さ１００１を有し、３つの部分を含んでいる。パケットヘッダ１００２は４バイトのサイズ１００３を有している。パケットヘッダ１００２に続いて、当該ストリームパケット１０００にはアダプテーションフィールド１００４が含まれ得る。その後に、ＤＶＢ暗号化パケットペイロード１００５を送信することができる。
【０１１８】
図１１は、図１０のトランスポートストリームパケットのヘッダ１００２の詳細な構造を示している。
【０１１９】
トランスポートストリームパケットヘッダ１００２は、同期ユニット（ＳＹＮＣ）１０１０と、パケット内のトランスポートエラーを示すことが可能なトランスポートエラーインジケータ（ＴＥＩ）１０１１と、特に後続のペイロード１００５におけるＰＥＳパケットの可能性のある開始部を示すことができるペイロードユニット開始インジケータ（PLUSI）１０１２と、当該トランスポートの優先度を示すトランスポート優先度ユニット（ＴＰＩ）１０１７と、当該パケットの任務（assignment）を決定するために使用されるパケット識別子（ＰＩＤ）１０１３と、当該トランスポートストリームパケットを解読するために要するＣＷを選択するために使用されるトランスポートスクランブル制御子（ＳＣＢ）１０１４と、アダプテーションフィールド制御子（ＡＦＬＤ）１０１５と、継続カウンタ（ＣＣ）１０１６とを有している。このように、図１０及び図１１は、暗号化されているＭＰＥＧ２トランスポートストリームパケットを示しており、該パケットは異なる部分を有している。即ち、
− パケットヘッダ１００２は平文である。該ヘッダは、パケット識別子（ＰＩＤ）番号、アダプテーションフィールドの存在、スクランブル制御ビット等の重要な情報を得るように働く。
− アダプテーションフィールド１００４も平文である。該フィールドはＰＣＲ等の重要なタイミング情報を含み得る。
− ＤＶＢ暗号化パケットペイロード１００５は、ＤＶＢアルゴリズムを使用して暗号化されている可能性のある実際の番組コンテンツを含む。
【０１２０】
放送された番組を解読するために要する正しいＣＷを選択するために、トランスポートストリームパケットヘッダを解析することが必要となる。このヘッダの概要が、図１１に示されている。放送された番組の解読にとり重要なフィールドは、スクランブル制御ビット（ＳＣＢ）フィールド１０１４である。このＳＣＢフィールド１０１４は、解読器が、放送された番組を解読するために何のＣＷを使用しなければならないかを示す。更に、該フィールドは、当該パケットのペイロードが暗号化されているか又は平文であるかを示す。全ての新しいトランスポートストリームパケットに対して、このＳＣＢ１０１４は解析されねばならない。何故なら、該ＳＣＢは時間にわたり変化し、パケット毎に変化し得るからである。
【０１２１】
以下においては、完全に暗号化されたストリーム上でのトリックプレイに関する幾つかの態様を説明する。
【０１２２】
これが関心のある主題であるという第１の理由は、平文上でのトリックプレイ及び完全に暗号化されたストリーム上でのトリックプレイは、一連の可能性における両極端であるからである。他の理由は、完全に暗号化されたストリームを記憶する必要があり得るようなアプリケーションが存在するからである。かくして、完全に暗号化されたストリーム上でトリックプレイを実行する技術を有することは有用なことであろう。基本原理は、記憶装置から十分に大きなブロックのデータを読み取り、これを解読し、該ブロック内のＩフレームを選択し、これを用いてトリックプレイストリームを構築することである。
【０１２３】
斯様なシステム１２００が図１２に示されている。
【０１２４】
図１２は、完全に暗号化されたストリームに対するトリックプレイの基本原理を示す。この目的のために、ハードディスク１２０１上に記憶されたデータが解読器１２０３にトランスポートストリーム１２０２として供給される。更に、ハードディスク１２０１はスマートカード１２０４にＥＣＭを供給し、その場合において、該スマートカード１２０４は該ＥＣＭから制御ワードを発生し、同制御ワードを解読器１２０３に送出する。
【０１２５】
上記制御ワードを使用して、解読器１２０３は前記暗号化されたトランスポートストリーム１２０２を解読し、解読されたデータをＩフレーム検出器及びフィルタ１２０５に送出する。そこから、上記データは空Ｐフレーム挿入ユニット１２０６に供給され、該ユニットは該データをセットトップボックス１２０７に伝達する。そこから、データはテレビジョン１２０８に供給される。
【０１２６】
記録が何を含むかの問題に関して幾つかの態様を説明する。
【０１２７】
単一チャンネルの記録を行う場合、該記録は該チャンネルの記録を後の段階で再生するために要する全てのデータを含まなければならない。特定の応答器に全てを記録することだけに頼ることもできるが、この方法では、記録したい番組を再生するのに必要なものより遙かに多くを記録することになる。これは、帯域幅及び記憶空間の両者が浪費されることを意味する。従って、こうする代わりに、本当に必要なパケットのみが記録されるべきである。これは、各番組に関して、ＰＡＴ（プログラム・アソシエーション（関連）・テーブル）、ＣＡＴ（条件付きアクセステーブル）等の全てのＭＰＥＧ２に必須のパケット、並びに明らかなことに各番組に対してビデオ及びオーディオパケット並びに何のパケットが番組に属するかを記述したＰＭＴ（プログラム・マップ・テーブル）を記録せねばならないことを意味する。更に、上記ＣＡＴ／ＰＭＴは当該ストリームの解読に要するＣＡパケット（ＥＣＭ）を記述することができる。記録が解読の後に平文でなされない限り、これらＥＣＭパケットも記録されねばならない。
【０１２８】
なされた記録が、完全な多重からの全てのパケットから構成されない場合、当該記録は所謂部分トランスポートストリーム１３００（図１３参照）となる。更に、図１３は完全なトランスポートストリーム１３０１も示す。ＤＶＢ規格は、部分トランスポートストリーム１３００が再生される場合、ＮＩＴ（ネットワーク情報テーブル）、ＢＡＴ（ブーケ・アソシエーション・テーブル）等の全ての通常のＤＶＢ必須テーブルが削除されることを求めている。これらのテーブルの代わりに、部分ストリームはＳＩＴ（選択情報テーブル）及びＤＩＴ（不連続情報テーブル）テーブルが挿入されるようにしなければならない。
【０１２９】
以下では、ＥＣＭの処理に関する幾つかの態様を説明する。
【０１３０】
トリックプレイの間において次のブロックへジャンプすることは、当該ストリームにおいて逆にジャンプすることを意味し得る。これは、トリックプレイ逆送りの場合のみならず、緩やかな速度におけるトリックプレイ順送りの場合でもあり得ると説明されるであろう。順方向ジャンプによる順方向トリックプレイ及び本来の逆方向ジャンプによる逆方向トリックプレイに関する状況は後に説明する。
【０１３１】
データが解読されねばならないという事実に起因して、固有の問題が発生し得る。条件付きアクセスシステムは、送信のために設計することができる。通常プレイにおいて、送信されたストリームは元のタイミングで再構築することができる。しかしながら、トリックプレイは、変化されたタイミングにより暗号的メタデータの処理に関して厳しい意味を有し得る。データはトリックプレイにより時間的に圧縮又は伸張され得るが、スマートカードのレイテンシは一定に留まり得る。
【０１３２】
トリックプレイストリームを形成するために、前述したデータブロックは解読器を通過し得る。この解読器は、当該データブロックを解読するために、暗号化処理に使用された制御ワードを必要とする。これらの制御ワードも、暗号化されＥＣＭに記憶され得る。通常のセットトップボックス（ＳＴＢ）では、これらのＥＣＭは同調された番組の一部であり得る。条件付きアクセス（限定受信）モジュールは、斯かるＥＣＭを抽出し、スマートカードに送出することができ、このカードが斯かるＥＣＭを解読する権利又は権能（authorization）を有するなら、該カードから解読された制御ワードを入力することができる。制御ワードは、通常は、例えば約１０秒等の相対的に短い寿命しか有さない。この寿命は、トランスポートストリームパケットのヘッダにおけるスクランブル制御ビットＳＣＢ１０１４により示すことができる。これが変化した場合、次の制御ワードが使用されねばならない。このＳＣＢの変化又はトグルが、図１４に垂直線により符号１４０２で示されている。
【０１３３】
図１４を参照すると、特に２つの異なる筋書き又はストリームタイプを区別することができる。
【０１３４】
図１４の下側の行に示されるストリームタイプＩによれば、ＥＣＭ当たり２つの制御ワード（ＣＷ）が供給される。
【０１３５】
図１４の上側の行に示されるストリームタイプIIによれば、ＥＣＭ当たり１つのみの制御ワード（ＣＷ）が供給される。
【０１３６】
図１４は、符号１４０３により示された連続して配列された期間又は区間Ａ，Ｂ，Ｃを有する２つのデータストリームを示している。図１４の上側の行１４００に示された筋書きでは、対応するＥＣＭ当たり本質的に１つの制御ワードが供給される。これとは対照的に、下側の行１４０１では、各ＥＣＭは２つの制御ワード、即ち現期間又はＥＣＭに関する制御ワード及び、更に、後続の期間又はＥＣＭの制御ワードを有する。このように、これら制御ワードの供給に関して幾らかの冗長性が存在する。
【０１３７】
前記短い寿命期間の間において、解読情報の項目は何回が送信することができるので、斯様な制御ワードの寿命期間を経る途中で斯様なチャンネルへ同調することは、次の制御ワードを待つことを意味しない。当該条件付きアクセスモジュールは、見つけた最初の固有のＥＣＭのみをスマートカードに送出して該カードに対するトラフィックを低減又は最少化する。というのは、斯かるカードは、かなり遅いプロセッサを有し得るからである。
【０１３８】
このことは、暗号化されたストリームに対するトリックプレイの限界が存在し得ることを示している。そこには、スマートカードの処理能力の限定された速度に由来する暗黙的上限速度が存在し得る。トリックプレイにおいて、１０秒なる制御ワード寿命はトリックプレイ速度係数により圧縮又は伸張され得る。ＥＣＭをスマートカードに送出すると共に解読された制御ワードを受け取るには、約半秒掛かり得る。制御ワードがＥＣＭに詰め込まれる方法はプロバイダ固有のものであり得、図１４に示されるように、ストリームタイプＩ及びストリームタイプIIに関して特に異なり得る。
【０１３９】
ＣＷ Ａは期間Ａを暗号化するために使用されたＣＷを示し、ＣＷ Ｂは期間Ｂを暗号化するために使用されたＣＷを示し、等々である。水平方向に、送信時間軸がプロットされている。ＥＣＭ Ａは、期間Ａの大部分の間に存在するＥＣＭであると定義することができる。その場合、ＥＣＭ Ａは現期間Ａのための、及びストリームタイプＩに関しては更に次の期間ＢのためのＣＷを保持することがわかる。一般的に、ＥＣＭは現期間のためのＣＷを少なくとも保持することができると共に、次の期間のためのＣＷを保持することができる。ザッピングのために、これは恐らく全ての又は多くのプロバイダにとり当てはまるであろう。
【０１４０】
更に続ける前に、解読器及び該解読器がＣＷをどの様に処理することができるかに関しての更なる情報を示す。解読器は２つのレジスタ、即ち"奇数"ＣＷ用のもの及び"偶数"ＣＷ用のものを含むことができる。"奇数"及び"偶数"は、ＣＷの値自体が奇数又は偶数であることを意味する必要はない。斯かる用語は、当該ストリームにおける２つの連続するＣＷの間を区別するために特に使用される。何のＣＷがパケットの解読に使用されるべきかは、パケットヘッダにおけるＳＣＢ１０１４により示される。従って、当該ストリームを暗号化するために使用されるＣＷは奇数と偶数との間で交互となる。図１４において、これは、例えばＣＷ Ａ及びＣＷ Ｃは奇数である一方、ＣＷ Ｂ及びＣＷ Ｄは偶数となることを意味する。スマートカードによる解読の後、ＣＷは、図１５に示されるように、前の値に上書きして、解読器の対応するレジスタに書き込むことができる。
【０１４１】
図１５は、偶数ＣＷを含む（レジスタ１５０１）及び奇数ＣＷを含む（レジスタ１５０２）２つのレジスタ１５０１，１５０２を示している。更に、スマートカードのレイテンシ１５００（スマートカードによりＥＣＭからＣＷを取り出す又は解読するために要する時間である）も図１５に示されている。
【０１４２】
ストリームタイプＩの場合、各ＥＣＭは２つのＣＷを保持し、結果として、両レジスタ１５０１，１５０２がＥＣＭの解読の後に上書きされ得る。レジスタ１５０１，１５０２のうちの一方が活性状態となり、他方が不活性状態となる。どちらのものが活性状態となるかは、ＳＣＢ１０１４に依存する。本例では、ＳＣＢ１０１４は期間Ｂの間において偶数レジスタ１５０１が活性状態のものであることを示すであろう。活性状態レジスタのみが、既に保持しているものと同一のＣＷにより上書きされ得る。何故なら、当該特定の期間の残りの解読のために依然として必要とされるからである。従って、不活性状態のレジスタのみが、新たな値で上書きすることができる。
【０１４３】
トリックプレイにおける期間Ｂを詳細に調べる。ＥＣＭが、この期間の開始点において、従ってＳＣＢトグル１４０２が横断された時点でスマートカードに送られると仮定する。問題は、この場合、どのＥＣＭをスマートカードに送ることができるかである。
【０１４４】
このＥＣＭは、期間Ｃの開始時に使用するためのスマートカードによる適時の解読を保証するためにＣＷ Ｃを保持していなければならない。
【０１４５】
該ＥＣＭは、当該解読器におけるＣＷの正しい利用可能性を妨害することなしにＣＷ Ｂも保持することができる。
【０１４６】
再び図１４を見ると、これは、ストリームタイプＩの場合、期間Ｂの開始時にＥＣＭ Ｂを送ることを意味し、ストリームタイプIIの場合ＥＣＭ Ｃを送ることを意味することがわかる。一般的に、２つのＣＷを保持する場合、現ＥＣＭを送ることができ、１つのＣＷのみを保持する場合は１期間先行して送ることができる。ＥＣＭを１期間先行して送ることは、埋め込まれたＥＣＭとは相反し得るので、その場合、後者はストリームから除去されねばならない。もっと一般化された方法にとっては、元のＥＣＭがトリックプレイ発生回路又はソフトウェアによりストリームから常に削除されることが好ましいであろう。しかしながら、これが常に当てはまるとは限らない。
【０１４７】
図１６は、高速順送りモードにおけるＥＣＭ処理を示す。
【０１４８】
ＳＣＢトグル１４０２により分離される複数の連続する期間１４０３において、複数のデータブロック１６００が再生され、その場合において異なるブロックの間で切り換え１６０１が生じる。
【０１４９】
ストリームタイプＩの場合、期間Ａ及びＢの間の境界ではＥＣＭ Ｂが送出される。ストリームタイプIIの場合、期間Ａ及びＢの間の境界ではＥＣＭ Ｃが送出される。更に、ストリームタイプＩによれば、期間Ｂ及びＣの間の境界でＥＣＭ Ｃが送出される。ストリームタイプIIの場合、期間Ｂ及びＣの間の境界ではＥＣＭ Ｄが送出される。
【０１５０】
ＥＣＭが正しい時点でトリックプレイのために利用可能になるために、ＥＣＭは別のファイルに記憶することができる。このファイルでは、何の期間（記録されるストリームの何の部分）にＥＣＭが属するかを示すことができる。ＭＰＥＧストリームファイルにおけるパケットには、番号を付すことができる。期間における最初のパケット（ＳＣＢトグル１４０２）の番号は、この期間１４０３に対するＥＣＭと一緒に記憶することができる。ＥＣＭファイルは、ストリームの記録の間に発生することができる。
【０１５１】
ＥＣＭファイルは、記録の間に作成することが可能なファイルである。ストリームには、ビデオデータを解読するために要する制御ワードを含むことが可能なＥＣＭパケットを配置することができる。各ＥＣＭは特定の期間、例えば１０秒にわたり使用することができ、この期間の間に何回（例えば１００回）も（繰り返し）送信することができる。ＥＣＭファイルは、そのような期間の全ての最初の新しいＥＣＭを含むことができる。ＥＣＭデータは、このファイルに書き込むことができ、何らかのメタデータが付帯し得る。先ず、連続番号（１から計数する）が与えられ得る。第２フィールドとして、ＥＣＭファイルはＳＣＢトグルの位置を含むことができる。これは、このＥＣＭを自身のコンテンツを正しく解読するために使用することができる最初のパケットを指すことができる。この場合、このＳＣＢトグルの時間位置が第３のフィールドとして後続し得る。これらの３つのフィールドには、ＥＣＭパケットデータ自体が後続し得る。
【０１５２】
ＥＣＭファイルに記憶されたＳＣＢトグルを使用して、斯様なトグルが横断されたかを、これがジャンプの間であってさえも、容易に検出することができる。正しいＥＣＭを送るために、ＥＣＭが１つのＣＷを含むか又は２つのＣＷを含むかを知ることが必要とされ得る。基本的に、これはわからない。何故なら、それはプロバイダ固有のものであり、秘密であるからである。しかしながら、これは、ＥＣＭを種々の時点で送出し、表示器上の結果を観察することにより実験的に容易に判定することができる。記憶装置自体内で実施化するのに特に適した代替方法は、下記の通りである。ＳＣＢトグルの時点において単一のＥＣＭをスマートカードに送出し、当該ストリームを解読し、来たる２つの期間内でＰＥＳヘッダをチェックする。ＧＯＰ当たり１つのＰＥＳヘッダによれば、各期間内に約２０個のＰＥＳヘッダが存在する。ＰＥＳヘッダの位置は容易に検出することができる。何故なら、パケットの平文ヘッダ内のPLUSIビットが、その存在を示し得るからである。正しいＰＥＳヘッダが最初の期間（スマートカードのレイテンシの後の）の間でのみ見つかった場合、当該ＥＣＭは１つのＣＷを含む。これらが第２の期間の間でも見つかった場合は、当該ＥＣＭは２つのＣＷを含む。このような状況が、図１７に示される。
【０１５３】
図１７は、１つのＣＷの検出に対する及び２つのＣＷ検出に対する状況を示す。理解されるように、暗号化されたコンテンツ１７００の異なる期間１４０３が設けられる。スマートカードのレイテンシ１５００により、ＥＣＭ Ａは解読されて、対応するＣＷを発生することができる。暗号化されたコンテンツ１７００を解読することにより、解読されたコンテンツ１７０１を発生することができる。図１７に更に示されるものは、ＰＥＳヘッダ１７０２、即ち期間Ａ（左）におけるＰＥＳヘッダＡ及び期間Ｂ（右）におけるＰＥＳヘッダＢである。
【０１５４】
図１７における１つのＣＷの期間Ｂの領域１７０３は、当該データが間違ったキーで解読され、従ってスクランブルされることを示す。このチェックは、記録の間に実行することができ、その場合、例えば２０ないし３０秒掛かるであろう。これはオフラインで実行することもでき、PLUSIにより示される２つのパケットのみ（各期間において１つ）をチェックすればよいから、非常に高速であり得る。適切なＰＥＳヘッダが利用可能でないという、ありそうにない事象においては、代わりに画像ヘッダを使用することができる。事実、検出のためには如何なる既知の情報も使用することができる。いずれにせよ、１／２ＣＷ指示子をＥＣＭファイルに記憶することができる。
【０１５５】
以下においては、特にスロー順送りストリームの処理に関する幾つかの態様を説明する。
【０１５６】
次に、トリックプレイＧＯＰに基づくスロー順送り、静止画及びステップモードを説明する。
【０１５７】
スローモーション順送りとも称すことができるスロー順送りは、表示画像が通常よりも遅い速度で進むようなモードである。或る形態のスロー順送りは、図７及び図８を参照して前述した技術により既に可能である。高速順送り速度をゼロと１との間の値に設定する結果、高速順送りトリックプレイＧＯＰの繰り返しに基づくスロー順送りストリームが得られる。平文ストリームにとり、これは適切な解決策であるが、暗号化されたストリームの場合、これは或る特定の条件ではＩフレームの一部の誤った解読につながり得る。この問題を解決する１つのオプションは、前記高速順送りトリックプレイＧＯＰを繰り返さないで、該トリックプレイＧＯＰのサイズを空のＰフレームの追加により延長することである。この技術は、事実、スロー逆送りをも可能にし得る。何故なら、これは、高速順送り／逆送りに使用されるトリックプレイＧＯＰに、従って独立に復号可能なＩフレームに基づくからである。
【０１５８】
このようなＩフレームに基づくスロー順送り又はスロー逆送りは、下記の理由により特別な場合には不適であり得る。通常プレイにおけるＩフレーム間の距離は約半秒であり、スロー順送り／逆送りの場合、該距離はスローモーション係数により乗算される。従って、このタイプのスロー順送り又はスロー逆送りは、正確にはスローモーションとして通常理解されているものではなく、実際には連続する画像の間に大きな時間的距離を伴うスライドショーのようなものである。
【０１５９】
静止画モードでは、表示画像は停止され得る。これは、静止画モードの期間にわたりＩフレームに空のＰフレームを追加することにより達成することができる。これは、最後のＩフレームからの画像が停止されることを意味する。通常プレイから静止画像に切り換える場合、これも、ＣＰＩファイル内のデータによる最も近いＩフレームであり得る。この技術は、高速順送り／逆送りモードの拡張であり、特にインターレース相殺が使用される場合、良好な静止画像が得られる。しかしながら、通常プレイ又はスロー順送り／逆送りから静止画へ切り換える場合、位置精度は常に満足のゆくものとは限らない。
【０１６０】
上記静止画モードは、ステップモードを実施するために拡張することができる。ステップコマンドは、当該ストリームを何れかの次の又は前のＩフレームに進める。ステップのサイズは、最小で１ＧＯＰであるが、整数の数のＧＯＰに等しい大きな値に設定することもできる。この場合、Ｉフレームのみが使用されるので、ステップ順送り及びステップ逆送りの両方が可能である。
【０１６１】
スロー順送りストリームの構築に対しては、多くの考慮事項がある。例えば、基本ストリームレベルでのスロー順送りストリームの構築は、完全に平文のデータに対してのみ実行することができる。結果として、通常プレイストリームが元々暗号化されていたとしても、スロー順送りストリームは完全に平文であろう。このような状況は、著作権保持者にとり許容不可能であり得る。更に、これは高速順送り／逆送りストリームの場合におけるよりも悪い。何故なら、真の高速順送り／逆送りストリームの場合におけるようにフレームの部分集合だけでなく、全ての情報（即ち、各々の及び全てのフレーム）が、当該スロー順送りストリーム内に平文で存在するからである。従って、平文のスロー順送りストリームから平文の通常プレイストリームを容易に再構築することができる。従って、通常プレイストリームが暗号化されているなら、該スロー順送りストリームも暗号化されるべきである。ＤＶＢ暗号器は家電装置では許可されないので、これは、スロー順送りストリームが、元々送信された暗号化されたデータストリームの暗号化されたデータパケットを用いてトランスポートストリームレベルで構築される場合にのみ実現することができる。
【０１６２】
以下においては、図１８ないし図６３を参照して、本発明の実施例によるシステムにおいてデータストリームを処理することができるようなシステムを説明する。
【０１６３】
以下で述べるシステムは、図１ないし図１７を参照して説明したシステムの何れかの枠内で且つ斯かるシステムの何れかとの組み合わせで実施化することができることを強調しておく。
【０１６４】
以下、図１８ないし図２２を参照して、本発明の実施例によるデータストリームを処理する方法を説明する。
【０１６５】
図１８は、完全に暗号化されたＭＰＥＧ２データストリーム１８００を示し、該ストリームは安全保護の理由でデータソースから再生装置への移行の間に完全に暗号化されるようなデータストリームである。
【０１６６】
暗号化されたデータストリーム１８００に関するメディアコンテンツのスローモーション再生であるスロー順送りトリックプレイモードを提供するために、以下に詳細に説明するような種々の操作ステップを実行することができる。
【０１６７】
第１ステップとして、図１９に示されるように、上記の完全に暗号化されたＭＰＥＧ２データストリーム１８００は、部分的に解読されると共に部分的に暗号化されたハイブリッドデータストリーム１９００を形成するように処理される。該ハイブリッドデータストリーム１９００は、当該暗号化されたデータストリーム１８００における隣接する暗号化されたフレーム１９０２の間の暗号化されたフレーム境界部分１９０１を、対応する解読されたフレーム境界部分１９０１により選択的に置換して、部分的に解読されると共に部分的に暗号化されたハイブリッドデータストリーム１９００を形成することにより得ることができる。更に詳細には、解読されたフレーム境界部分１９０１の一部は、画像開始コード部１９０３により形成される。フレーム境界部分１９０１は、個々に解読することが可能な最小の部分とすることができ、該部分の一部は（所望の）画像開始コード部１９０３である。この処理は、当該ビデオコンテンツの連続するフレームの間の画像開始コード１９０３を（完全に又は部分的に）含むパケット１９０１が平文になる（即ち、部分１９０１が解読されたものとなる）一方、当該データストリーム１９００の残りの（多くの場合、主たる）部分、即ち実際のオーディオ又はビデオコンテンツ１９０２が暗号化されたままとなるように実行することができる。しかしながら、画像開始コード１９０３は、以下で説明するように、トリックプレイ動作を可能にすべく復号された態様で存在する。
【０１６８】
図２０からわかるように、ハイブリッドデータストリーム１９００は、該ハイブリッドデータストリーム１９００の隣接するフレーム１９０２をフレーム境界部分１９０１／画像開始コード部１９０３において分割することにより更に処理される。言い換えると、順次の連続的ハイブリッドデータストリーム１９００は、対応するフレーム境界部分１９０１及び対応するフレーム１９０２を含むような別々の部分に分離される。
【０１６９】
更に、図２１から分かるように、分離されたフレーム２０００の幾つか、即ちＢフレームは、所定のスロー順送り率に従って複数回（本実施例では３回）繰り返される。アンカフレーム（Ｉフレーム及びＰフレーム）は、空フレーム２００１を用いて繰り返される。本例では、スロー順送り率は、３なる係数である。これは、暗号化されたデータストリーム１８００のビデオコンテンツが、当該スロー順送りモードにおいて、通常プレイ動作モードと比較して１／３の速度で再生されるべきことを意味する。
【０１７０】
トリックプレイストリームを得るために、（空のフレームを挿入する代わりに）アンカフレームを複数回繰り返すことも可能であると言える。個々の部分的に暗号化され且つ部分的に解読された部分２０００を複数回繰り返すと共に、次いで、複製された分割フレーム２０００を互いに接続することにより、画像開始コード１９０１及びフレーム１９０２の異なるグループから得られる隣接する部分が、互いに適切な形で合致しなくなってしまう。このため、これらの部分は、図２２に示すようにトリックプレイに適したハイブリッドデータストリーム２２０１が得られるように、所望なら、接続部分２２００を選択的に修正することにより結合される。
【０１７１】
以下においては、図２３を参照して本発明の一実施例による処理装置２３００を説明する。
【０１７２】
該処理装置２３００により、図１８ないし図２２を参照して説明した種々の方法のステップを実行することができる。
【０１７３】
図２３は、暗号化された再生されるべきオーディオビジュアルコンテンツが記憶されたハードディスク２３０１を示している。
【０１７４】
当該処理装置２３００は、中央処理ユニット（ＣＰＵ）２３０２等の制御ユニットにより制御することができ、斯かるＣＰＵはユーザインターフェース２３０３を用いてユーザにより制御することができる。ユーザインターフェース２３０３により、ユーザは当該処理装置２３００の動作を制御することができ、例えば通常プレイモード又はスロー順送りモード等のトリックプレイ動作を開始させることができる。
【０１７５】
対応する制御信号が中央処理ユニット２３０２からハードディスク２３０１に送られると、暗号化された形態のオーディオビジュアルコンテンツが該ハードディスク２３０１から解読器２３０４に送られる。解読器２３０４は、暗号化されたデータストリーム１８００における隣接するフレーム１９０２の間の暗号化されたフレーム境界部分を、解読されたフレーム境界部分１９０１により選択的に置換して、部分的に解読されたデータストリーム１９００を発生するように構成されている。
【０１７６】
部分的に解読されたデータストリーム１９００は、該部分的に解読されたデータストリーム１９００の隣接するフレーム１９０２をフレーム境界部分１９０１で分割する分割ユニット２３０５に供給される。分割されたハイブリッドストリーム部分２０００のシーケンスは、所定の複製率に従って該分割フレーム２０００を複数回（図１８〜２２の例では、３回）複製する複製ユニット２３０６に供給されるが、該所定の複製率はマイクロプロセッサ２３０２により及び／又はユーザインターフェース２３０３を操作するユーザにより規定又は決定することができる。
【０１７７】
図２１に示した個々の部分は、次いで、複製ユニット２３０６から接着ユニット又は接続ユニット２３０７に供給することができ、該接続ユニットは図２１の複製された分割フレームを接続して、トリックプレイが可能なストリーム２２０１を発生する。
【０１７８】
このストリームは、スピーカを備えるモニタ等の再生ユニット２３０８に供給することができ、該ユニットにおいては、このコンテンツの再生がマイクロプロセッサ２３０２の制御の下で及び／又はユーザインターフェース２３０３を介してのユーザの制御の下で可能となる。
【０１７９】
暗号化されたデータストリーム２２０１を再生のために解読すべく、再生ユニット２３０８内の更なる解読ユニット（図示略）を予見することも可能である。
【０１８０】
前記解読ユニット２３０４は、暗号化されたデータストリーム１８００における隣接するフレーム１９０２間の暗号化されたフレーム境界部分のみを、フレーム境界部分１９０１を含む解読されたパケットにより選択的に置換し、全ての他のフレーム部分１９０２は暗号化されたままに維持する。これは高度の安全保護を保証する。何故なら、トリックプレイストリーム２２０１を発生するために平文でなければならない選択された部分のみしか解読されていないからである。
【０１８１】
後に詳細に説明するように、分割ユニット２３０５は２つの連続するフレームのデータを含み得る平文パケットを、各々が斯かるフレームの一方からのデータのみを含むような２つのパケットに変換し、これらパケットの各々に詰め物をすることができる。接着ユニット２３０７は、図２１の複製された分割フレームを、フレーム境界部分１９０１が２つのフレーム１９０２の間に延びている位置２２００を識別することに基づいて、及び斯かる識別された位置を補正することに基づいて接続することができる。
【０１８２】
このような補正は、フレーム境界部分１９０１のサイズの部分を決定することを含むことができる。該サイズが大きすぎる場合、短縮することができ、該サイズが小さい場合は、長さを増加させることができる。
【０１８３】
フレーム１９０２は、イントラ符号化フレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）又は双方向予測フレーム（Ｂフレーム）とすることができる。処理されるコンテンツ１８００はビデオデータ及び／又はオーディオデータのデータストリームとすることができる。再生ユニット２３０８は、接続ユニット２３０７に接続されたデータストリームを再生することができる。暗号化されたデータストリーム１８００は、暗号化されたＭＰＥＧ２データストリームとすることができる。
【０１８４】
以下においては、図２４を参照して、本発明の他の実施例によるデータ処理装置２４００を説明する。
【０１８５】
データ処理装置２４００は前記データ処理装置２３００とは、図２４の場合に解読ユニット２３０４が予定されていない点で異なる。この場合、ハイブリッドデータストリーム１９００が、ハードディスク２３０１から直接供給される。これは、解読ユニット２３０４がハードディスク２３０１内に統合されているか、又はデータがハードディスク２３０１に既に図１９に示すような態様で記憶されているかの何れかを意味する。
【０１８６】
以下においては、本発明の実施例によるスロー順送りトリックプレイ再生に関する更なる詳細を説明する。
【０１８７】
次に、ストリームの別個のフレームへの分割を説明する。
【０１８８】
トランスポートレベルでスロー順送りストリームを構築するのを可能にするためには、個々のフレームが一連のトランスポートストリームパケットとして利用可能であることが有利である。フレーム当たり１ＰＥＳパケットの場合、これは当然に生じる。ＰＥＳ及びトランスポートストリームパケットは整列されているので、ＰＥＳパケットは一連のトランスポートストリームパケットに含まれる。ＧＯＰ当たり１ＰＥＳパケットの場合、これはＩフレームの開始にだけ当てはまる。全ての他のフレーム境界は、殆どの場合、パケット内の何処かに位置される。このパケットは、当該２つのフレームからの情報を含む。従って、先ず、このパケットを２つのパケットに分割することができ、最初のものは最初のフレームからのデータを含み、第２のものは次のフレームからのデータとなる。上記分割の結果の斯かる２つのパケットの各々は、アダプテーションフィールド（ＡＦ）により詰めることができる。
【０１８９】
この状況が図２５に示されている。
【０１９０】
図２５は、フレーム境界でのパケットの分割を示す。特に、図２５は、各々がヘッダ２５０１とフレーム部分２５０２とを有する複数のＴＳパケット２５００を示す。図２５に示されたデータストリームの中央部分から分かるように、ヘッダ２５０１と２つの連続するフレーム２５０２とを有するパケットが、各々が別個のヘッダ２５０１と、後続するアダプテーションフィールド２５０３と、後続する対応するフレーム２５０２とを有するような２つの別個の部分に分割される。
【０１９１】
パケットの分割は、平文のストリームにとっては困難ではない。第１のオプションは、図２６に示されるように、通常プレイのデータを完全に解読することである。図２６は、通常プレイデータの解読の後のスロー順送りの構築を示す。ハードディスク２６０１からの暗号化された通常プレイのデータ２６００は、平文ストリーム２６０３を発生する解読器２６０２に供給される。該平文ストリーム２６０３は、異なるフレームを図２５に示した態様で分割するためのフレーム分割ユニット２６０４に供給される。次いで、このデータは、スロー順送りストリームを構築するスロー順送り構築ユニット２６０５に供給され、該スロー順送りストリームは次いでセットトップボックス２６０６に供給される。
【０１９２】
記憶された完全に暗号化されたストリーム２６００又は記憶されたハイブリッドストリームの解読及びスロー順送りモードは困難ではない。何故なら、解読器２６０２により当該ストリームにおいてストリームデータがスキップ又は複製されることはないからである。記憶されたストリーム２６００（完全に暗号化された又はハイブリッドの）は、解読器２６０２を介して単に通常より遅いレートで供給され、これは、埋め込まれたＥＣＭ（エンタイトルメント制御メッセージ）にとり何の問題もないことも意味する。この場合、解読器ユニット２６０２から到来する平文ストリーム２６０３はパケットを分割するために、又は実際にフレーム分割ユニット２６０４における如何なる必要なストリーム操作を実行するためにも使用することができる。この場合、結果としてのスロー順送りストリームは平文ストリームである。
【０１９３】
暗号化された通常プレイストリームからの暗号化されたスロー順送りストリームの構築は、トランスポートレベルで実行される。何故なら、家電装置でのＤＶＢ（デジタルビデオ放送）暗号器の使用は特別な場合に許可されないからである。このため、全てのフレーム境界上に僅かの平文パケット２７００及び２７０２のみを伴うハイブリッドストリーム（図２７参照）が必要となる。図２７は、更に、Ｉフレーム２７０３、Ｂフレーム２７０４又はＰフレーム２７０５に属する暗号化されたパケット２７０１も示している。
【０１９４】
以下、記憶されたストリームが完全に暗号化されている場合、上記のようなストリームを記憶装置の再生側でどの様に発生することができるかを説明する。この場合、図２６の解読器ユニット２６０２は、必要なパケットのみを解読するような選択型とすることができる。しかしながら、好ましくは、当該ストリームは図２８に示すように既にハイブリッドストリームとして記憶されているものとする。
【０１９５】
図２８は、記憶されたハイブリッドストリーム２８００に対するスロー順送りの構築を示す。図２８に示す配列において、ハードディスク２６０１とフレーム分割ユニット２６０４との間には解読器ユニット２６０２は予定されていない。しかしながら、この場合に、セットトップボックス２６０２に解読器ユニット２８０１を予定することができる。
【０１９６】
この場合、上記ハイブリッドストリームにおける平文パケット２７００、２７０２は２つのフレームからのデータを含むパケットの分割も可能にしなければならない。これは、後に詳細に述べる規準により保証することができる。しかしながら、シーケンスヘッダコード又は画像開始コードの何らかの部分が、依然として、暗号化されたパケット内に位置する可能性がある。この場合、理想的な分割は容易には可能ではない。事実、分割は暗号化されたパケットと平文パケットとの間でなされ得る。これらの問題に対する解決策を、以下に更に詳細に説明する。その状況においては、空のＰフレームのみがＩフレームに連結されるか又はその逆とする。フレームに基づくスロー順送りの場合、他のタイプの連結も考えることができ、それらの中にはＢフレームのＢフレームに対する連結もある。その結果は、図２９を参照して明確にされるように、これらのフレーム境界における或る種の接着アルゴリズムとなる。
【０１９７】
図２９はデータストリームを示し、前のフレーム２９００、現フレーム２９１２及び次のフレーム２９０１が示されている。前のフレーム２９００の終了部には、３バイトの画像開始コード２９０２が設けられる。更に、現フレーム２９１２の開始部には、１バイトの画像開始コード２９０３が予定される。ここで、次のフレームに来ると、当該パケットのフレーム終了部が、前に、１バイトの画像開始コード２９０４を有する。次のフレーム２９０１の開始部には、３バイトの画像開始コード２９０５が設けられる。図２９は、連結点に不完全な画像開始コードが存在し得ることを示している。これが、接続領域２９０６において接着を必要とさせ得る。このように、接着は、Ｂフレーム２９０７とＢフレームの繰り返し２９０８との間で実行されるべきである。
【０１９８】
図２９は、パケットヘッダ２９０９、平文データ２９１０及び暗号化されたデータ２９１１を特に示している。図２９の例では、Ｂフレームの開始部及び終了部に１バイトのみの画像開始コードが存在する。結果的に、連結点では２バイトが失われている。後に詳述する接着アルゴリズムは、このような問題を直すことができる。この接着のためには、画像開始コードがどの様に分割されるかが知られねばならない。この情報は後に詳述する方法により得ることができる。
【０１９９】
以下においては、フレームの繰り返しを詳細に説明する。
【０２００】
スロー順送りモードにおいては、デコーダは、何とかして、画像の表示をスロー順送り係数に従って繰り返すように強制されなければならない。Ｉフレームからの結果の画像の繰り返しを強制するために、空のＰフレームを使用することができる。この技術は、Ｐフレームからの結果の画像にも適用することができる。しかしながら、この技術はＢフレームには容易に適用することができない。何故なら、空のＰフレームは、常にＩフレーム又はＰフレームであるアンカフレームを指すからである。これは、実際に、如何なる空のフレームにも当てはまる。従って、Ｂフレームから得られた画像の繰り返しは他の方法で実現されなければならない。可能性のある方法は、Ｂフレームデータ自体を繰り返すことである。繰り返されるＢフレームは元のＢフレームと同一のアンカフレームを指すので、結果として得られる画像も同一となるであろう。Ｂフレームに対するデータの量は、空のＰフレームに対するよりは通常は大幅に多いが、それでも一般的には、Ｉフレームに対するよりは著しく少ない。いずれにせよ、伝送もスローモーション係数により乗算されるので、少なくとも平均ではビットレートの増加は必要でない。
【０２０１】
Ｉフレーム又はＰフレームからの画像の繰り返しを強制するために使用される空フレームは、インターレース打消型のものとすることができ、かくして、これら画像に対するインターレースアーチファクトを低減する。しかしながら、斯様な低減はＢフレームからの画像に対しては容易に可能ではない。何故なら、繰り返しが空フレームによって強制されるのではなく、Ｂフレームデータ自体の繰り返しによるからである。従って、これらＢフレームは元のインターレース効果を有するであろう。インターレース打消がＩフレーム及びＰフレームに対して使用されたとしたら、これは非常にぎこちなく見える。何故なら、インターレース効果を伴う及び伴わない画像が、表示される画像のストリームに順に現れるからである。現在のところ、スロー順送りストリームを構築するにはインターレース打消を伴わない空フレームのみを使用する方がよいと信じられる。
【０２０２】
Ｉフレーム及びＰフレームの繰り返しは、伝送ストリーム内に、元のＩフレーム又はＰフレームの後に空のＰフレームを挿入することにより実行することができる。このような方法は、空のＰフレームにより後続されたＩフレームを有する高速順送り／逆送りストリームに対して使用することができる。しかしながら、この方法は、Ｂストリームを伴う記憶された伝送ストリームから構築されるスロー順送りストリームの場合におけるように、Ｂフレームも含むストリームに対しては絶対的に正しいものではない。伝送データから表示ストリームへの再配列により、Ｉフレーム及びＰフレームが誤った位置で繰り返され、これによりフレームの通常の表示順序を妨げるであろう。これが、図３０及び図３１に示されている。
【０２０３】
図３０は、通常プレイにおける再配列の効果を示している。図３０は、伝送順序３０００及び表示順序３００１を示している。特に、図３０は通常プレイにおける再配列の効果を示している。上側のラインは、Ｉフレーム２７０３、Ｐフレーム２７０５及びＢフレーム２７０４を有する１２フレームのＧＯＰサイズの通常プレイ伝送（transition）ストリームを示す。明瞭化のために、次の伝送ＧＯＰの最初の４つのフレームも示されている。図３０の下側のラインは、表示順序への再配列後のストリーム３００１を示している。インデックスは表示フレーム順序を示している。ＭＰＥＧ２規格ＩＳＯ／ＩＥＣ13818-2:1995(E)（特に、第２４及び２５頁参照）によれば、再配列は下記のように実行することができる：
− Ｂフレームは元の位置を維持する；
− アンカフレーム（即ち、Ｉフレーム及びＰフレーム）は次のアンカフレームの位置にシフトされる。
【０２０４】
図３１は、スロー順送りモードにおける再配列の効果を示す。特に、図３１は、伝送順序３１００、再配列後の順序３１０１及び表示される画像の順序３１０２を示す。通常プレイストリームから構築されるスロー順送りストリームをより詳細に調べると、図３１の一番上のラインは、この場合のスローモーションストリームの最初の部分の伝送順序３１００を示し、３なるスローモーション係数を仮定している。空のＰフレームをＩフレーム及びＰフレームの後に挿入することができ、Ｂフレームは繰り返すことができる。図３１の真ん中のラインは再配列の効果を示している。図３１の一番下のラインは、この場合に、空のＰフレームによりＩフレーム及びＰフレームがどの様に繰り返されるかを示している。空のＰフレームは、前のアンカフレームからの結果の画像のコピーであるような表示画像となり、該前のアンカフレーム自体も空のＰフレームであり得る。図３１では、インデックスにより示される通常表示順序３１０２が、フレームＩ４の表示が２つの部分に分割される故に妨害されることがわかる。最後のフレームＩ４だけが正しい位置に表示される。これは、Ｂフレームが誤って復号され得ることも意味する。
【０２０５】
以下においては、上記のような欠陥を如何にして補正するかの幾つかのオプションを説明する。１つの可能性が図３２に示される。図３２はアンカフレームの前に空のＰフレームを挿入するものを示す。図３２における３つの行は、図３１における３つのラインと同様である。図３２において、一番上のライン３１００に示すように、空のＰフレームは、記憶装置から抽出された伝送ストリームにおけるアンカフレームの前に挿入される。再配列されたストリーム３１０１では、空のＰフレームはアンカフレームの後に配置される。これは、図３２の表示画像３１０２から明らかなように、アンカフレームの正しい繰り返しのためにあるべき位置である。
【０２０６】
しかしながら、空のＰフレームを回避することが何故適切であり得るかの意見が存在する。１つは、ＧＯＰ内でのエラーの増殖に関するものである。Ｐフレームは前のアンカフレームに依存し、Ｂフレームは周りのアンカフレームに依存する。セットトップボックスへの伝送の間のデータエラーは符号化エラーとなり、従って画像における乱れとなる。このエラーがアンカフレームであると、該エラーはＧＯＰの終わりまで伝搬する。何故なら、後続のＰフレームは、このアンカフレームに依存するからである。また、Ｂフレームの影響を受ける。何故なら、これらＢフレームは、復号のために、妨害された周囲のアンカフレームからの画像を使用するからである。これは、画像の乱れがＧＯＰの終わりに向かって徐々に増加するという結果を有し得る。これは、ＧＯＰサイズが非常に大きく、従って時間的に非常に長くなり得るようなスロー順送りの場合に特に重要であり得る。一方、Ｂフレームにおけるデータエラーは非常に限られた影響しか有さない。何故なら、Ｂフレームには他のフレームは依存しないからである。従って、画像の乱れは当該Ｂフレーム及びその繰り返しに限られる。デジタルインターフェースではデータエラーは生ぜず、空のＰフレームの使用を回避することには第２の利点が存在し得るとの意見があり得る。もし、これらがインターレース打消型のものである場合、これらは当然復号された画像においても変化し、結果として後続のフレームにとっても復号エラーとなる。従って、インターレース打消は不可能であろう。
【０２０７】
空フレームの構築を考えると、幾つかのタイプの空Ｂフレームを構築することができる。これらは、付加的なエラー増殖が生ぜず、インターレース打消を使用することができるという利点を有し得る。
【０２０８】
可能性のあるタイプの空Ｂフレームは、順方向予測空Ｂフレーム（Ｂｆフレームと称する）及び逆方向予測空Ｂフレーム（Ｂｂフレームと称する）である。
【０２０９】
Ｂフレームは、通常、双方向予測的であるが、単方向予測Ｂフレームも存在し得る。後者の場合、これら単方向予測Ｂフレームは順方向予測的又は逆方向予測的であり得る。順方向予測的とは、符号化の間においてアンカフレームが後続のＢフレームを予測するために使用されることを意味する。従って、順方向予測Ｂフレームからの結果としての画像は、復号の間に前のアンカフレームから再構築される。これは、Ｂｆフレームが前のアンカフレームの繰り返しを強制することを意味する。従って、これは、空Ｐフレーム又はＰｅフレームと同一の効果を有する。Ｂｂフレームは反対の効果を有する。該フレームは、自身に後続するアンカフレームの表示を強制する。両タイプのＢフレームに対して、インターレース打消バージョンも可能である。
【０２１０】
以下においては、このような空Ｂフレームを、スロー順送りストリームの構築のためにどの様に使用するかを説明する。
【０２１１】
Ｂｂフレームに基づく第１の可能性が図３３に示されている。
【０２１２】
Ｂｂフレームは、アンカフレームの前に挿入され、再配列の間において自身の位置を維持する。アンカフレームは、次のアンカフレームの位置にシフトされる。該Ｂｂフレームは、再配列されたストリームにおいて自身に後続するアンカフレームの表示を強制する。
【０２１３】
他のオプションは、図３４に示されるように、Ｂｆフレームの使用である。
【０２１４】
Ｂｆフレームは、伝送ストリームにおけるアンカフレームの後に挿入される。再配列されたストリームにおけるアンカフレームの繰り返し表示が、斯かるアンカフレームに後続するＢｆフレームにより強制される。
【０２１５】
Ｂｆフレームの使用は、高速順送り及び高速逆送りストリームの構築のための空Ｐフレームの使用に類似している。事実、その場合にはＢｆフレームの使用も可能であり、かくして、トリックプレイの発生を更に一層共通化させる。しかしながら、Ｂｆフレームが高速順送り及び高速逆送りのために使用される場合、再配列の効果が考慮されねばならない。これは、ＰＴＳ／ＤＴＳ及び時間基準等の高速順送り／逆送りストリームにおける幾つかのパラメータが適切に選択されなければならないことを意味する。
【０２１６】
次に、個々のフレームの接着を説明する。
【０２１７】
特に、不完全な画像開始コードの場合におけるフレームの接着を説明する。スロー順送りストリーム内の連結点における所要の接着動作を決定するためには、先ず、元のストリームが何処で個々のフレームに明確に分割されるが明らかでなければならない。以下においては、ＧＯＰ当たり又はフレーム当たり１個のＰＥＳパケットの実際的状況を考察する。
【０２１８】
フレーム当たり１つのＰＥＳパケットの場合、元のストリームは図３５に示されるように、PLUSIを伴うパケットと先行するパケットとの間で分割することができる。
【０２１９】
図３５には、フレーム当たり１つのＰＥＳパケットの場合のストリームの分割が示されている。図３５に示されるデータストリームは、平文パケットヘッダ３５００、アダプテーションフィールド３５０１、平文データ３５０２、暗号化されたデータ３５０３及び平文ＰＥＳヘッダ３５０４を含んでいる。更に、PLUSIプレゼントは符号３５０５により示され、ＰＥＳヘッダは符号３５０６により示される。
【０２２０】
個々のフレームは、複数の完全な元のパケットを有する。従って、パケットの分割は必要ではない。このフレーム分割は完全に暗号化されたストリームにおいても実行することができるが、スロー順送りストリームの構築には何らかの平文データへのアクセスが依然として必要である。PLUSIを伴うパケットの開始部における分割は、２つのパケットにわたって広げられた画像開始コードは存在しないことも意味する。個々のフレームは、自身の正しく且つ完全な画像開始コードを含む。従って、この場合は、接着動作は必要ではない。
【０２２１】
しかしながら、ＧＯＰ当たり１つのＰＥＳパケットの場合、状況は異なる。ＰＥＳヘッダが先行しない限り、フレーム間の分割は新たなフレームの画像開始コードにおいてなされる。
【０２２２】
分割点を決定するために下記のアルゴリズムを使用することができる：
１．元のストリームは、PLUSIビット組、画像開始コード及び画像コーティング拡張部を伴うパケットに関して同時に調査される；
２．PLUSIビット組を伴うパケットが最初に遭遇された場合は、このパケットの開始部で分割がなされる（画像開始コード３６００及び画像コーティング拡張部３６０１を含み、図３６を参照されたい）。次いで、当該ストリームは、画像コーティング拡張部をサーチされる。これが見つかった後、当該サーチはポイント１で説明したように継続される；
３．画像開始コードが最初に遭遇された場合は、分割は該画像開始コードの開始部においてなされる。多くの場合、これは、当該画像開始コードを含むパケットは２つのパケットに分割されねばならず、これらのうちの最初のものは前のフレームに割り当てられ、第２のものは後続のフレームに割り当てられることを意味する（画像開始コード３６００の開始部におけるストリームの分割を示す図３７を参照されたい。この場合、アダプテーションフィールドの挿入箇所は符号３７００で示されている）。両パケットはアダプテーションフィールド３７００により詰められる。この場合、第２のパケットのペイロードは画像開始コード３６００で開始する。元のパケットの記録タイムスタンプは、当該分割の結果としての２つのパケットの各々にコピーされる。２つのフレームの連結点において分割からの２つのパケットが使用されるか又は元のパケットが使用されるかは、後述するように特定の状況に依存する。次いで、当該ストリームは画像コーティング拡張部をサーチされる。これを見つけた後、当該サーチはポイント１で説明したように継続される；
４．画像コーティング拡張部が最初に遭遇された場合、画像開始コードは検出不可能に違いない。何故なら、これは部分的に暗号化されているからである。これは、現平文領域が画像開始コードの幾つかのバイトで開始することを意味する。この場合、分割は現平文領域の最初の平文パケットの開始部でなされる（画像開始コード３６００内での当該ストリームの分割を示す図３８を参照されたい。該図は画像開始コードのバイト３８００及び画像コーティング拡張部３６０１も示す）。ポイント１で説明したサーチは、画像コーティング拡張部３６０１を見つけた後に継続される。
【０２２３】
上述したアルゴリズムの結果、フレーム当たり１つのＰＥＳパケットを持つストリームに関する正しい分割点も得られるであろう。更に、該アルゴリズムは、平文ストリーム及び前述したハイブリッドストリームに対する適用のためにも設計されている。
【０２２４】
接着は、前記アルゴリズムのポイント４からのみ生じ得るような不完全な画像開始コードの場合においてのみ必要である。従って、ポイント４のみが、非理想的な分割点となる。平文ストリームは理想的な分割点のみを有する。何故なら、画像開始コードが常に見つかるからである。従って、この場合、接着は必要でない。しかしながら、ハイブリッドストリームは非理想的な分割点を含むであろう。以下に述べる方法は、当該画像開始コードのうちのどれだけ多くのバイトが非理想的分割点の何れの側にあるかを決定するために使用することができる。非理想的分割点の効果は、後に詳細に説明する。
【０２２５】
次に、何れかのタイプの空Ｐフレームが斯様な非理想的分割点に挿入されるような状況を考察する。最初の空のフレームを如何に扱うかを以下に説明する。分割点の後の画像開始コードの部分に等しい複数のバイトが、最初の空フレームの画像開始コードから削除される。中間の空フレームは変更されない。最後の空フレームは、後続のフレームの画像開始コードの欠けている部分のために補正されなければならない。従って、この欠けている部分は最後の空フレームの終了部に追加することができる。理想的分割点で挿入された空フレームに対し変更は必要ない。
【０２２６】
以下においては、Ｂフレームの繰り返しを考察する。Ｂフレームが両側に理想的分割点を有する場合、繰り返しのために如何なる接着動作も必要でない。しかしながら、当該フレームの何れかの側に非理想的分割点が存在すると、接着動作が必要となるか又は有利となり得る。元のフレーム及びその繰り返しが、同一のＢフレームの系列を形成する。該系列の開始部及び終了部では接着動作は必要でない。何故なら、ここでは、フレームは通常プレイストリームにおけるように同じフレームに接続されるか、又は空フレームに接続されるかの何れかであるからである。最初の場合では、不連続部は存在しない。何故なら、当該データの通常の順序が、この位置で回復されるからである。２番目の場合に対する解決策は、先に示した。従って、Ｂフレームの終了部が同じＢフレームの開始部に接続されるような中間の連結点のみが考察されねばならない。ここで述べる例は、図２９を参照して前述した例であり、明瞭化のために図３９において一層詳細に繰り返し説明する。
【０２２７】
図３９は、連結点における不完全な画像開始コードを示す。
【０２２８】
正しい接着のためには、Ｂフレームの終了部及び開始部における画像開始コード（ＭＰＥＧ２内では、開始コードは長さが４バイトであり得る）のバイト数を知る必要がある。終了部におけるバイト数をｎにより、開始部におけるバイト数をｍにより表すと、理想的分割の場合、ｎ＝０及びｍ＝４である。非理想的分割点の場合、或るフレームに対する数ｎ及び後続のフレームに対する数ｍは、以下に示すような方法により決定することができる。
【０２２９】
ｎは決して４に等しくはならないことは明である。何故なら、その場合、分割は画像開始コードの開始点においてなされたことになり、結果としてｎ＝０となるからである。一方、ｍは決して０ではあり得ない。何故なら、その場合、画像開始コードは完全に前のフレーム内となり、分割は理想的位置でなされたことになり、かくして、ｍ＝４となるからである。従って、０≦ｎ≦３及び１≦ｍ≦４が通常の状況である。
【０２３０】
或る同一のフレームＮに対して数ｎ及びｍを得るために、これら数は、当該フレームの周囲の２つの分割点の情報から抽出されねばならない。かくして、ｎ及びｍは、繰り返されるべきＢフレームの終了部及び開始部における画像開始コードのバイト数を表す。結果として、これらは、中間の連結点の前及び後の画像開始コードの複数のバイトも表すことになる。
【０２３１】
次に、ｎ＋ｍ＝４と仮定する。これは、当該Ｂフレームを囲む両分割点が理想的である場合である。しかし、その場合には接着動作が必要とされないことが既に分かっている。しかしながら、これは両分割点が非理想的である場合でもあり得る。これは、図４０に示された状況である。
【０２３２】
図４０は、従って、ｎ＋ｍ＝４なる例を示している。
【０２３３】
フレームＮの最後のパケットが符号４０００で示され、図４０は、更に、符号４００１により示されたフレームＮの最初のパケットも示す。境界４００２では、接着動作は必要ではない。画像開始コードのバイト（ｎ＝３）が符号４００３により示され、画像開始コードのバイト（ｍ＝１）が符号４００４により示されている。
【０２３４】
ｎ＋ｍ＝４なる事実は、正しい量の画像開始コードバイトが連結点に存在し、接着動作は必要ないことを意味する。
【０２３５】
しかしながら、図４１はｎ＋ｍ＞４の状況を示している。
【０２３６】
これは、連結点に１、２又は３バイト過剰に存在することを意味する。この場合、ｎ＋ｍ−４に等しい数のバイトが第２フレームの開始部から削除される。これは、これら平文バイトを、詰め込みバイトを含むアダプテーションフィールド（ＡＦ）により置換することにより達成される。アダプテーションフィールドが既に存在する場合、その長さがｍ＋ｎ−４だけ増加されねばならず、破棄されるべきデータは、規格によれば１６進数のＦＦを有する詰めバイトにより置換される。
【０２３７】
ｎ＋ｍ＞４及びｎ＜３なる特別なケースでは、接着を行わないことも可能である。実効的に、基本ストリーム詰め込みを得る。
【０２３８】
接着動作が必要な箇所は、符号４１００により示される。本例において、画像開始コードのバイト（ｎ＝２）は符号４１０１により示されている。画像開始コードのバイト（ｍ＝３）は符号４１０２により示されている。更に、画像開始コードのバイト（ｎ＝２）は符号４１０３により示され、画像開始コードのバイト（ｍ＝２）は符号４１０４により示されている。アダプテーションフィールドを用いて置換されたバイトの位置は、符号４１０５により示されている。
【０２３９】
図４２を参照すると、ｎ＋ｍ＜４と仮定されている。
【０２４０】
これは、連結点における画像開始コードから１、２又は３バイトが不足していることを意味する。この場合、何のバイト又は複数のバイトがないかを知る必要がある。ｎ及びｍは両方ともわかるので、不足しているバイトは固有に識別することができる。かくして、不足バイトは新たなパケットに配置され、該パケットは更にアダプテーションフィールドにより詰められる。この接着パケットは、次いで、上記２つのフレームの間に配置される。この接着パケットは、符号４２００により示されている。符号４２０１は画像開始コードのバイト（ｎ＝２）を示し、符号４２０２は画像開始コードのバイト（ｍ＝１）を示す。また、符号４２０４は挿入されたバイト（４−ｎ−ｍ）を示す。また、符号４２０５は画像開始コードのバイト（ｍ＝１）を示す。
【０２４１】
以下においては、タイムスタンプを用いたフレーム及びパケットの位置決めを説明する。
【０２４２】
この説明は、各パケットに予め添付された記録タイムスタンプを用いた、フレーム及びパケットのスロー順送りストリームの時間軸上への配置を扱う。説明は、元の通常プレイフレームの配置で開始する。次いで、Ｂフレームの繰り返し及び圧縮が説明される。続いて、空フレームの配置が説明される。最後に、ＰＣＲに関する幾つかの問題が議論される。
【０２４３】
次に、元の通常プレイフレームの位置決めを説明する。
【０２４４】
必要なデータが受信される前に復号が開始すると、復号問題が発生し得る。このような可能性のある復号問題は、スロー順送りストリームの場合、フレームデータの終わりから、このフレームのＤＴＳまでの距離がスロー順送りストリーム及び通常プレイストリームに対して同一であるなら回避することができる。これは、対応するＤＴＳの当該フレームデータの開始における距離を通常プレイストリームと同一に維持すると共に、このフレームのパケットを元の通常プレイストリームからのと同一のパケット距離で配置することにより達成することができる。
【０２４５】
この状況が、ＤＴＳまでの変更されない距離を示す図４３に示されている。ＤＴＳまでの距離は、図４３に示されるよりも大幅に大きくすることができる。
【０２４６】
図４３は、符号４３００で示された通常プレイにおける状況を示すと共に、符号４３０１で示されたスロー順送りにおける状況を示している。
【０２４７】
フレームデータの開始時点は、このフレームの開始におけるシステムタイムカウンタの値により与えられる。これは、事実上のＰＣＲ値ＰＣＲＳにより示される。上付文字Ｎ及びＳは、記録された通常プレイストリームにおける元の値及びスロー順送りストリームにおける新たな値を、各々、示す。この場合、フレームの開始に対する配置規則は、
ＤＴＳＳ−ＰＣＲＳＳ＝ＤＴＳＮ−ＰＣＲＳＮ （５）
により与えられ、これは、
ＤＴＳＳ−ＤＴＳＮ＝ＰＣＲＳＳ−ＰＣＲＳＮ （６）
に書き換えることができる。
【０２４８】
通常プレイストリームにおけるフレームの元の位置に対するスロー順送りストリームにおける該フレームのオフセット（offset）は、
offset＝ＰＣＲＳＳ−ＰＣＲＳＮ （７）
により与えられ、これは、
offset＝ＤＴＳＳ−ＤＴＳＮ （８）
に変形することができる。
【０２４９】
必要とされるＤＴＳ値は、各スロー順送りフレームに対して、及び、必要なら、ＧＯＰ内のＤＴＳを持たない通常プレイフレームに対しても計算することができる。通常プレイストリームにおける及びスロー順送りストリームにおける全ての元のフレームのＤＴＳが利用可能となるので、これらフレームのオフセットを、それらの新たな及び元のＤＴＳ値の間の差として計算することができる。次いで、このオフセットは、当該フレームを配置すると共に、このフレームのデータ内に存在するＰＣＲＳのＰＣＲ値を補正するために使用される。後者は容易である。即ち、オフセットが元のＰＣＲ値に単に加算される。ＰＣＲ拡張部は変更されない。これは、ＤＴＳとＰＣＲとの間にドリフトが生じないことを保証する。何故なら、当該補正が両ケースとも上記オフセットに等しいからである。この場合、新たな及び元のＰＣＲベース（base）値の間の関係は、
ＰＣＲbaseＳ＝ＰＣＲbaseＮ＋offset （９）
により与えられる。
【０２５０】
フレームの位置決めは、もっと幾らか困難である。位置決めは、全パケットに予め添付された4バイトの記録タイムスタンプ（ＴＳＴ）の補正により達成される。この目的のために、前記オフセットは９０ｋＨｚ基準から２７ＭＨｚ基準に再計算することができる。素直な選択は、上記オフセットを３００により乗算することであろう。しかしながら、この場合、通常プレイからスロー順送りに切り換える場合のＰＣＲクロック周波数の可能性のあるジャンプが考慮されねばならない。このようなジャンプは、そうあるべきように、タイムスタンプカウンタのクロックが記録の間にＰＣＲにロックされていたなら、決して発生しない。しかしながら、何らかの理由でタイムスタンプがＰＣＲにロックされていない場合、ジャンプするＰＣＲクロック周波数は、それでも、追加の乗算係数Ｍを使用することにより回避することができる。この場合、この係数は、記録された通常プレイストリームにおけるＰＣＲを含む最新の２つのパケットのタイムスタンプ及びＰＣＲ値の比に等しい。最新のとは、現フレームの開始前の最後の２つのＰＣＲパケットを意味する。この比は、ロックされたタイムスタンプの理想的な場合、１に等しくなる。これらの少なくとも２つのＰＣＲパケットをＰ（ｋ−１）及びＰｋにより示すと、当該フレームの全パケットのタイムスタンプに関するオフセットは、
ＴＳＴoffset＝３００ｘoffsetｘＭ （１０）
により与えられ、ここで、
Ｍ＝(ＴＳＴＮ{Ｐｋ}−ＴＳＴＮ{Ｐ(k-1)})／(ＰＣＲＮ{Ｐｋ}−ＰＣＲＮ{Ｐ(k-1)}) （１１）
である。
【０２５１】
この式におけるＰＣＲ値は、事実、２７ＭＨｚクロックに基づく全ＰＣＲ値となる。これは、ＰＣＲベース及び拡張から下記の方法で計算することができる：
ＰＣＲ＝３００ｘＰＣＲbase＋ＰＣＲext （１２）
【０２５２】
パケットＰ（ｋ−１）とＰｋとの間でＴＳＴ又はＰＣＲ値に折り返し（wrap）が存在するとＭの計算に変な結果生じ得ることは明らかである。これは、簡単に回避することができる。パケットＰｋに対する値がパケットＰ（ｋ−１）に対するより小さい場合、ＴＳＴ又はＰＣＲの範囲に対応する値が、この減算に先立ちパケットＰｋに対する値に加算されねばならない。これは、ＴＳＴ又はＰＣＲに対するレジスタは通常必要とされるよりも１ビット広くなければならないことを意味する。ＴＳＴに対しては、これは、この条件が生じた場合には上記追加ビットが１に設定され、それ以外ではゼロに設定されることも意味する。残りのビットは、常に、元のＴＳＴビットに等しい。
【０２５３】
計算されたＴＳＴオフセットは、このフレームの全パケットのタイムスタンプを補正するために使用される。これは、オフセット値が、記録されたタイムスタンプに加算されることを意味する。
【０２５４】
以下においては、Ｂフレームの繰り返しを説明する。
【０２５５】
Ｂフレームからの結果の表示画像の繰り返しは、Ｂフレームデータの繰り返しにより実施される。この結果、スロー順送りストリーム内に同一のＢフレームの系列が得られる。この系列の最初のフレームの配置は、元の通常プレイフレームの位置決めを扱う場合におけるのと類似する。残りのフレームは、反復Ｂフレームと呼ばれる。これらは、最初のフレームと同様に処理することができ、これは、オフセットがスロー順送りストリーム及び元の記録されたストリームにおけるＤＴＳ値の間の差として計算されることを意味する。記録されたフレームのＤＴＳは、同一のＢフレームの全系列に対して同一である。スロー順送りストリームにおいては、或るフレームのＤＴＳは、デルタにより増加された前のフレームのＤＴＳと常に等しくなる。これは、反復ＢフレームＢＲのオフセットも、下記の式により計算することができ、該式においてＢＬは前のＢフレームを示す：
offset{ＢＲ}＝offset{ＢＬ}＋Delta （１３）
【０２５６】
次いで、上記オフセットは、先に説明した態様で、特定のＢＲフレームのパケットの（変換後の）タイムスタンプ及び恐らくは現在のＰＣＲを補正するために使用される。
【０２５７】
図４４は、同一のＢフレームの系列の境界における等しいオフセットを示す。該状況は通常プレイに対して（符号４４００）及びスロー順送りに対して（符号４４０１）示されている。
【０２５８】
当該連結点に空フレームが挿入されないなら、或る系列の最初のＢフレームのオフセットは、スロー順送りストリームにおける前のフレームのオフセットと等しいことを示すことができる。２つの状況が、この要件を満たす。最初のものは、空フレームの事前挿入の場合にＢフレームが前のアンカフレームと連結される場合である。第2のものは、Ｂフレームが前のＢフレームと連結される場合である。図４４は、２つのＢフレームの連結に関する効果を示している。同一のことが、事実、系列の終了部にも当てはまる。また、ここでは、連結点の周りの２つのフレームのオフセットは、この点に空フレームが挿入されないなら同一となる。図４４も、これを２つの連結されたＢフレームに関して示している。他の状況は、Ｂフレームの後挿入が用いられる場合の、Ｂフレームの後続のアンカフレームへの連結である。
【０２５９】
これは、斯様な連結点の周りの２つのフレームが、通常プレイストリームにおけるのと同じ態様で接続されることを意味する。このような理由により、斯様な連結点においては、元のパケットが常に使用され、当該パケットが２つのフレームからの情報を含む場合における分割の結果としての２つのパケットは決して使用されない。また、（既に前述したように）斯様な点では接着が必要でないことも明らかである。全ての他の連結点では、もし存在するなら、分割からの２つのパケットが使用される。
【０２６０】
以下においては、Ｂフレームの時間圧縮を説明する。 Ｂフレームの持続時間が通常は1フレーム時間よりも小さいことが予測され得る。平均では、これは真であるが、時にはＢフレームの伝送時間は１フレーム時間よりも大きくなり得る。大凡３０秒の期間での測定において、１.４フレーム時間のＢフレームが検出された。この測定が図４５に示されている。平均のＢフレームデータ長は０.６フレームに等しいが、規則的に、Ｂフレームデータの持続時間は１フレーム時間より大きくなる。
【０２６１】
図４５は、時間が秒でプロットされた横軸を持つグラフ４５００を示す。該グラフ４５００の縦軸４５０２に沿って、フレームの長さがフレーム時間の数でプロットされている。
【０２６２】
Ｂフレームのパケットの、これらのタイムスタンプのＴＳＴオフセットでの補正による位置決めは、Ｂフレームの持続時間が１フレーム時間より短い限り、正しい結果となる。しかしながら、スロー順送りストリームにおけるＢフレームが１フレーム時間より大きい場合、該フレームの終了部が後続のフレームと重なる。何故なら、これらフレームの開始部は1フレーム時間の差で配置されるからである。これは、完全には正しくない。何故なら、最後の反復Ｂフレームは後続のフレームとは決して重ならないからである。１フレーム時間より大きなＢフレームに関する状況を図４６で明確にする。図４６は、Ｂフレームが１フレーム時間より大きな場合のデータの重なりを示す。
【０２６３】
図４６は、通常プレイの状況４６００、圧縮無しのスロー順送りの状況４６０１及び圧縮を伴うスロー順送りの状況４６０２を示す。フレーム時間は、符号４６０３により示される。Ｂフレームは符号４６０４を有し、次のフレームは符号４６０５を有し、前のフレームは符号４６０６を有し、圧縮されたＢフレームは符号４６０７により示されている。更に、隣接するフレームの間の重なりは符号４６０８により示されている。
【０２６４】
前及び次のフレームのタイプは、上述した効果には何の影響も有さない。従って、これらはアンカフレーム、Ｂフレーム又は空フレームとさえすることもできる。
【０２６５】
これは、同一のＢフレームの系列のうちの最後を除く全Ｂフレームは、時間的に圧縮されねばならないことを意味する。この圧縮は、局部的ビットレートを、全通常プレイストリームの概ね最大ビットレートのレベルまでさえ増加させ得る。この増加を可能な限り制限するために、Ｂフレームのパケットは利用可能なフレーム時間にわたり均等に分散される。Ｂフレームの最初のパケットのタイムスタンプは、先に示したオフセット規則で計算される。ＢフレームのパケットがＰｊにより示される場合（インデックスｊは当該Ｂフレーム内のパケット番号である）、スロー順送りストリームにおける圧縮されたＢフレームの最初のパケットのタイムスタンプは：
ＴＳＴＳ{Ｐ１}＝ＴＳＴＮ{Ｐ１}＋ＴＳＴoffset （１４）
により与えられる。
【０２６６】
当該フレームの後続するパケットに対するタイムスタンプの増加は、1フレーム時間を該フレームのパケット総数により除算したものに対応する値に等しい。接着パケット及びＰＣＲパケット等のＢフレームの終了部における追加のパケットは、この数に含まれなければならない。このパケットの数をＮｂにより示し、圧縮されたＢフレームのパケットの間の距離をｄｂにより示すと、この距離は：
ｄｂ＝３００ｘDelta／Ｎｂ （１５）
により与えられる。
【０２６７】
スロー順送りストリーム及び圧縮されたＢフレームの残りのパケットのタイムスタンプは、この場合：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄｂ （１６）
により与えられる。
【０２６８】
非理想的な場合、上記距離の計算のための乗算係数３００は、圧縮されたＢフレームの最後のパケットと後続のフレームの最初のパケットとの間のパケット距離の問題となり得る。これは、上記係数３００をとらず、代わりに上記デルタをオフセットに関して説明したのと同じ方法で変換することにより解決することができる。しかしながら、実用的な解決策は、パケットの実際の数より1だけ大きいＮｂの値をとることである。図４７は、不規則なパケット距離及び１フレーム時間より大きな持続時間を持つＢフレームが、如何にして、1フレーム時間の持続時間及び一定のパケット距離を持つＢフレームに圧縮されるかを示す。1フレーム時間は、タイムスタンプの３００ｘDeltaの増加に対応する。Ｎｂがパケットの実際の数より１だけ大きくなるように選択される事実の結果、圧縮されたＢフレームの終了部に幾らかの空きスペースが得られる。
【０２６９】
従って、図４７は均一に分布されたパケットを持つＢフレームの圧縮を示す。
【０２７０】
図４７は、圧縮されていない状態４７００及び圧縮された状態４７０１を示すと共に、Ｂフレーム４７０２及び１フレーム時間内に圧縮されたＢフレーム４７０３を示す。
【０２７１】
Ｂフレームに対する等しいパケット分布の方法を、圧縮が必要とされる場合のみでなく全ての場合に使用することができる。しかしながら、殆どの場合では、これはＢフレームが伸張されることを意味する。Ｂフレームの最初のパケットに対するＴＳＴオフセットの適用は、このパケットのＤＴＳまでの距離が通常プレイストリームに等しいことを意味する。この場合、伸張の結果、当該Ｂフレームデータの終了部と対応するＤＴＳとの間において元のものより時間距離が小さくなる。しかしながら、フレームのＤＴＳは当該フレームデータの開始の１フレーム時間よりは決して早くなり得ないことを理解することができる。その理由は下記の通りである。元のストリーム及びフレームのＤＴＳは、定義により、前のフレームのＤＴＳより常に１フレーム時間遅い。この前のフレームのＤＴＳは、このフレームのデータの終了より決して早いことはあり得ず、従って現フレームのデータの開始よりも決して前ではない。これは、任意のフレームのＤＴＳは、このフレームのデータの開始より少なくとも１フレーム時間遅いことを意味する。これは、フレームデータが１フレーム時間内に均一に分布されていても、常に該フレームデータの終了より後であることも意味する。従って、説明した等しいパケット分布は、最後の反復Ｂフレームを除く全てのＢフレームに適用されるべきである。簡略化のために、圧縮され及び伸張されたフレームは圧縮されたフレームと称することができる。
【０２７２】
接着は、Ｂフレームの等しい系列におけるＢフレームの間においてのみ必要である。従って、可能性のある追加の接着パケットは、圧縮されたＢフレームの終わりにのみ追加され、それ以外では決して追加されない。付加的ＰＣＲパケットは、最後の反復Ｂフレームの終わりを除き、Ｂフレームの終わりに追加される。何故なら、この点には空きがないからである。これは、付加的ＰＣＲは圧縮されたＢフレームの終了部においてのみ追加されることも意味する。従って、これらのパケットに対しては特別な配置アルゴリズムは必要ではない。何故なら、これらは全て圧縮アルゴリズムに含まれるからである。
【０２７３】
Ｂフレームの圧縮の結果は、フレームデータ内のＰＣＲの値の補正は、最早、斯様なＢフレームにとり正しくないということである。この場合において該ＰＣＲ値が如何にして補正されるか、及び圧縮されたＢフレームの終了部に追加されるＰＣＲの値が如何にして計算されるかを、以下に説明する。次いで、空フレームの挿入が説明される。
【０２７４】
挿入される空フレームが何処に配置されるかを決定しなければならない。スロー順送りストリームにおける他のフレームの位置を考察すると、特に大きなスローモーション係数の場合は、主な時間間隙は空フレームが挿入されるべき箇所に存在することが明らかである。過度のＰＣＲ距離による問題を避けるために、空フレームは、この領域内に分散されねばならず、且つ、各空フレームはＰＣＲを含まなければならない。このような理由により、連続する空フレームの間の距離は、1フレーム時間となるように選定される。最初の空フレームは、前のフレームに直接連結される。これが、図４８に示される。
【０２７５】
図４８は、空フレームの配置を示し、前のフレーム４８００、空フレーム４８０１、フレーム時間４８０２後の更なる空フレーム４８０１が配置される等々のシーケンスを示している。次のフレームは符号４８０３により示されている。
【０２７６】
配置アルゴリズムは、空フレームの事前若しくは事後挿入又はタイプには無関係である。しかしながら、空フレームの最初のパケットの配置と、残りのパケットの配置との間は区別されるべきである。
【０２７７】
以下においては、空フレームの最初のパケットの配置を説明する。
【０２７８】
図４９から分かるように、ここでは、空フレームの最初のパケットの位置決めを説明する。前のフレーム４９００には、複数の空フレーム４９０１、４９０２、４９０３等々が後続する。空フレームの最初のパケットはＦＰｉにより示され、ここで、ｉは空フレームのシーケンス内での当該空フレームのフレーム番号である。
【０２７９】
最初の空フレームの最初のパケットであるＦＰ１の配置で開始すると、このパケットのタイムスタンプを導出する幾つかのオプションが存在する。その１つは、先行するフレームの最後のパケットのスロー順送りタイムスタンプに値ｄを加算することである。この最後のパケットをＰＬとして示すと、最初の空フレームの最初のパケットのタイムスタンプは、
ＴＳＴＳ{ＦＰ１}＝ＴＳＴＳ{ＰＬ}＋ｄ （１７）
により与えられる。
【０２８０】
上記ｄなる値も、幾つかの方法で選択することができる。或る可能性は、先行するフレームの最後の２つのパケットのタイムスタンプの間の差を、ｄのための値として使用することである。この場合、これらタイムスタンプは、スロー順送りストリームから又は元の記録されたストリームからの何れかから取り出すことができる。何故なら、圧縮されたフレームは、いずれにせよ、空フレームに決して先行することはないからである。前のフレームの最後の２つのパケットをＰ(L-1)及びＰＬにより示すと、ｄの値は、
ｄ＝ＴＳＴ{ＰＬ}−ＴＳＴ{Ｐ(L-1)} （１８）
により与えられる。
【０２８１】
ｄの計算のためのタイムスタンプがスロー順送りストリームから取り出される場合、ＦＰ１の計算のための前記式も：
ＴＳＴＳ{ＦＰ１}＝２ｘＴＳＴＳ{ＰＬ}−ＴＳＴＳ{Ｐ(L-1)} （１９）
と書くことができる。
【０２８２】
後続の空フレームの最初のパケットのタイムスタンプは、ＦＰ１のタイムスタンプに対する１フレーム時間に対応する値の反復的加算により得ることができる。この値は、この場合、３００ｘDeltaとなるように選択することができる。かくして、後続する空フレームの最初のパケットのタイムスタンプは：
ＴＳＴＳ{ＦＰｉ}＝ＴＳＴＳ{ＦＰ(i-1)}＋３００ｘDelta （２０）
により与えられる。
【０２８３】
以下においては、空フレームの残りのパケットの配置を説明する。
【０２８４】
空フレームのパケットはＰｊにより示され、ここで、ｊは該空フレーム内のパケット番号である。Ｐ１は、上記においてＦＰにより示された空フレームの最初のパケットである。
【０２８５】
残りのパケットの位置は、空フレームの最初のパケットから導出される。このために、パケット間の距離が決定されねばならない。これは、事実、該距離が短すぎない限り厳しくはない。何故なら、十分な空間が利用可能であるからである。ここでは、２つのオプションを述べる。
【０２８６】
第１のオプションは、先に述べたｄなる値をここでも使用することである。この場合、この値は、空フレーム内のパケットのタイムスタンプを増加させるために使用される。かくして、これらタイムスタンプは：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄ （２１）
により与えられる。
【０２８７】
これが図５０に示され、該図は前のフレーム５０００、第１の空フレーム５００１及び第２の空フレーム５００２のシーケンスを示している。従って、図５０は、前のフレームに基づく空フレームのパケット距離を示す。
【０２８８】
第２のオプションは、空フレームのパケットを１フレーム時間にわたり均一に分散させることである。この場合、増分は、当該空フレームのパケット数により除算された１フレーム時間に対応する値に等しい。このパケット数をＮｅにより、パケット間の距離をｄｅにより各々示すと、該距離は：
ｄｅ＝３００ｘDelta／Ｎｅ （２２）
により与えられる。
【０２８９】
この場合、空フレーム内のパケットのタイムスタンプは：
ＴＳＴＳ{Ｐｊ}＝ＴＳＴＳ{Ｐ(j-1)}＋ｄｅ （２３）
により与えられる。
【０２９０】
この状況が図５１にも示され、該図は前のフレーム５０００が第１の空フレーム５００１及び第２の空フレーム５００２により後続されるのを再び示している。
【０２９１】
従って、図５１は１フレーム時間にわたり均一に分散された空フレームのパケットを示す。
【０２９２】
次に、ＰＣＲに関する幾つかの態様を説明する。
【０２９３】
先ず、スロー順送りストリームには追加のＰＣＲは挿入されないと仮定することができる。Ｉフレームは通常は１フレーム時間より大幅に大きいので、該フレームがＰＣＲを含むことは非常にありそうなことである。Ｐフレームの場合、確率は早くも低減される。Ｂフレームは殆どの場合１フレーム時間より小さいので、多くのＢフレームはＰＣＲを含まないであろう。これは、Ｂフレームが繰り返されたとしても、スロー順送りストリームではＰＣＲの大きなギャップが生じるであろうことを意味する。一般的に、ＰＣＲ間の最大距離は、スローモーション係数により増加されると言うことができる。これは、明らかに、スロー順送りストリームへの追加のＰＣＲの挿入を必要とする。
【０２９４】
フレームデータに埋め込まれた元のＰＣＲとは別に、付加的ＰＣＲが空フレーム及びＢフレームの終わりに追加されねばならない。後者は最後の反復Ｂフレームの終わりを除いて成り立つ。何故なら、この点には空きはないからである。これら対策によっても、上記最大距離が、問題となるレベルまでではないが、依然としてＤＶＢ規格の要件を超過する可能性がある。一般的に、当該状況は高速順送り／高速逆送りに対するよりは有利である。
【０２９５】
フレームに埋め込まれたＰＣＲの補正は、少なくとも圧縮無しのフレームに関しては先に説明した。何らかの他の方法が、空フレームにおける及びＢフレームの終わりにおける付加的ＰＣＲのＰＣＲ値を計算するために並びに圧縮されたＢフレーム内のＰＣＲのために有利である。第１のオプションは下記の規則である。即ち、ＰＣＲ値は、スロー順送りストリームにおける前のＰＣＲの、これらＰＣＲを含む２つのパケットの実際のスロー順送りタイムスタンプの間の差で補正された値に等しい。現ＰＣＲ及び前のＰＣＲを含むパケットを、各々、Ｐｃ及びＰ(c-1)により表すと、スロー順送りストリームにおける現ＰＣＲは：
ＰＣＲＳ{Ｐｃ}＝ＰＣＲＳ{Ｐ(c-1)}＋ＴＳＴＳ{Ｐｃ}−ＴＳＴＳ{Ｐ(c-1)} （２４）
により与えられる。
【０２９６】
ここでも、ＰＣＲはベース及び拡張部から計算された全ＰＣＲ値を指す。この式は、理想的な場合は完全であるが、非理想的な場合は周波数変動、従ってかなりのＰＣＲジッタにつながる。これは、先に計算された補正係数Ｍを適用することにより防止される。現ＰＣＲは：
ＰＣＲＳ{Ｐｃ}＝ＰＣＲＳ{Ｐ(c-1)}＋(ＴＳＴＳ{Ｐｃ}−ＴＳＴＳ{Ｐ(c-1)})／Ｍ （２５）
により与えられた。
【０２９７】
当該パケットに挿入されるべきＰＣＲのベース及び拡張部はＰＣＲ値から下記のようにして計算される：
ＰＣＲbase＝int(ＰＣＲ／３００) （２６）
ＰＣＲext ＝ＰＣＲ−３００ｘＰＣＲbase （２７）
【０２９８】
事実、式（２６）及び（２７）は全てのＰＣＲ値を調整するために使用され得るので、圧縮されていない元のフレームに埋め込まれたＰＣＲのものも含む。しかしながら、前記補正係数による計算は丸め誤差につながり得、これら誤差は蓄積し得るので、ＤＴＳに対してＰＣＲタイムベースのゆっくりしたドリフトが生じ得る。従って、このドリフトをゼロにリセットするために、圧縮されていないフレームに埋め込まれたＰＣＲの補正が、先に説明したようにオフセット値の加算により実行されねばならない。
【０２９９】
以下においては、ハイブリッドストリームが何処で作成され得るかを説明する。
【０３００】
ここで述べるハイブリッドストリームは幾つかの場所で作成することができる。これらは、事実、平文Ｉフレームを持つストリームに対して可能なのと同一の場所である：
１．衛星放送の場合における放送機又はアップリンクにおいて；
２．ケーブルネットワークの場合におけるケーブルヘッドエンドにおいて；
３．安全な認可ドメインの場合における住宅用ゲートウェイにおいて；
４．記憶装置の記録側において。
しかしながら、僅かな平文パケットしか伴わないストリームの場合、第５の場所、即ち：
５．記憶装置の再生側において、
が可能である。
【０３０１】
図５２は、ハイブリッドストリームへの変換にとり可能性のある場所を示す。
【０３０２】
図５２の状況は、放送機５２００が衛星アンテナ５２０１に信号を放送するものである。衛星アンテナ５２０１は該信号を衛星５２０２に送信することができ、他の衛星アンテナ５２０３が、これら信号を受信することができる。次いで、斯かる信号はケーブルヘッドエンド５２０４に供給することができ、該ケーブルヘッドエンドから記憶装置５２０５に供給することができる。又は、上記信号は住宅用ゲートウェイ５２０６に供給することができ、該ゲートウェイから記憶装置５２０７に供給することができる。他の例として、上記信号は衛星アンテナ５２０３から記憶装置５２０８に供給することもできる。図５２の位置１〜５において、ハイブリッドストリームへの変換が可能である。
【０３０３】
位置１及び２は実現するのが困難であろう。何故なら、プロバイダはここには限られた影響しか有さないからである。記憶装置にとっては、ハイブリッドストリームへの変換が位置１、２又は３で実現されるかは、実際に、差はない。オプション３は、良い代替となる。これは、認可されたドメインのための住宅用ゲートウェイにおけるプロバイダの立場を改善し得る。３つの全ての場合において、記憶装置は自身の記録入力端においてハイブリッドストリームを受信する。これは、少なくとも通常プレイ及びトリックプレイの発生のためでないなら、記憶装置に解読及びスマートカードは必要でないことを意味する。しかしながら、キーフレーム等の検出を用いる記憶装置内にメタデータ抽出機能が存在する場合、解読は依然として必要である。
【０３０４】
ハイブリッドストリームを構築するために非常にありそうな位置は、記憶装置の記録側にあるケース４であろう。これは、記録側における部分的解読を必要とするかも知れないが、トリックプレイの発生のために解読が必要とされないという利点を依然として有している。いずれにせよ、記録されるストリームはハイブリッドストリームであることが好ましい。
【０３０５】
記録が全パケットが暗号化された状態でなされるケース５においても、安全なトリックプレイを生成することは可能である。完全な解読の代わりに、必要とされるパケットのみを解読し、残りを依然として暗号化されたままにすることも可能である（図５３参照）。
【０３０６】
図５３は、完全に暗号化された記録から安全なトリックプレイを発生するものを示している。記録装置５３００は、暗号化されたＭＰＥＧ２データ５３０１を出力し、後者をブロック選択器ユニット５３０２に供給する。そこから、データは解読器５３０３に供給され、該解読器は部分的に暗号化されたＭＰＥＧ２データ５３０４を発生する。この部分的に暗号化されたＭＰＥＧ２データはフレーム選択器５３０５に供給され、そこから、該データはトリックプレイ発生ユニット５３０６に供給される。トリックプレイ発生ユニット５３０６は、ＭＰＥＧ２ ＤＶＢ準拠のトランスポートストリームの部分的に暗号化されたデータ５３０７を発生し、該データは次いでＭＰＥＧ２デコーダ又は解読器５３０８に供給することができる。
【０３０７】
しかしながら、これらのパケット及び平文と共に記録することにより可能であるような、前もってＣＰＩ（図４参照）を作成する利点は利用することはできない。しかしながら、支配的に暗号化されたトリックプレイストリームを作成することは依然として可能である。当該システム構成は、トリックプレイ構築ユニットが、トランスポートストリームレベルで構築された暗号化されたストリームを発生し、ＥＣＭの挿入がオプションではなく必須であるというようなものである。
【０３０８】
以下においては、平文であるべきパケットを如何にして選択するかを説明する。
【０３０９】
ハイブリッドストリームが構築される場合、どのパケットが平文でなければならないかが決定されねばならない。必要とされる平文データの検出及び選択を可能にするために、当該ビデオストリームを先ず完全に解読することができる。次いで、このデータの位置が該平文ストリーム内で決定され、該データが位置する平文パケットが元のストリームの暗号化されたパケットを置換してハイブリッドストリームを形成する。
【０３１０】
選択された平文データに対して、３つの規準を使用することができる：
１．存在するなら、ＤＴＳ／ＰＴＳ及びＰＥＳヘッダは変更することができる。この目的のために、ＰＥＳヘッダデータの全てを平文にすることができる。これは、PLUSIビット組を持つものからＰＥＳヘッダの最後のバイトを含むものまでの範囲のパケットが全て平文にされることを意味する。
２．シーケンスヘッダ及びシーケンス拡張部からの何らかの情報は必要とされ得る。この目的のために、シーケンスヘッダから画像開始コードまでのデータの全てが平文にされる。シーケンスヘッダ及び画像開始コードは、４バイトコードをチェックすることにより検出される。これらの４バイトは、必ずしも、１つの同一のパケットに位置するとは限らない。シーケンスヘッダ及び画像開始コードは、斯かる４バイトの最後が見つかった場合に検出される。ハイブリッドストリームの構築のための過度のバッファリングを避けるために、シーケンスヘッダの４バイトを含むものから画像開始コードの４バイトを含むものまでの範囲のパケットが全て平文にされる。これは、結果としてのハイブリッドストリームにおいてシーケンスヘッダ及び画像開始コードを検索する場合に、幾つかの変な状況につながり得る。これは後述する。
３．画像開始コードは、フレーム境界を検出するために必要とされる。従って、画像開始コードを含むパケットは平文にされなければならない。画像開始コードに続く２バイトも、平文でなければならない。これらのバイトは、変更される必要があり得る時間基準、及びＩフレーム、Ｐフレーム又はＢフレームを識別する画像符号化タイプを含む。更に、幾らかの情報が、画像コード拡張部から必要である。この目的のために、画像開始コードから画像コード拡張部の終わりまでのデータの全てが平文にされる。画像開始コードは、前記４バイトが発見された場合に検出される。過度のバッファリングを避けるために、画像開始コードの４バイトを含むものから画像コード拡張部の最後のバイトを含むものまでの範囲のパケットが全て平文にされる。この結果、全てのフレーム境界上で平文パケットとなり、これは特定のトリックプレイストリームの構築に必要とされるもの以上のものである。しかしながら、これはスローモーション順送りストリームの構築には必要である。
【０３１１】
過度のバッファリングが何を意味するか、及びこれが何を生じるかの問題に関して、ハイブリッドストリームが構築される場合、元の暗号化されたストリーム及び解読されたストリームからのパケットが１つのストリームに結合されねばならないと言うことができる。リアルタイムに実行される場合、何らかのバッファリングが必要とされ得る。画像開始コードが２つのビデオパケット上に分散されていると仮定すると、この４バイトの画像開始コードは暗号化されたストリームにおいて最後のバイトが見つかった時点で検出される。完全な画像開始コード及び平文を有するということは、この最後のバイトを持つビデオパケットのみならず、先行するビデオパケットも平文でなければならないことを意味する。
【０３１２】
これらの２つのビデオパケットの間に他のデータがあい得、通常はあるであろう。基本的に、これは大量のパケットであり得る。図５４は、Ｉフレームの終わりの画像開始コードが２ビデオパケットにわたって広がっているような状況の一例を示している。
【０３１３】
更に詳細には、図５４は、画像開始コード５４０２の一部を含むようなＩフレーム５４０１を含むバッファ５４００を示す。次いで、オーディオパケット５４０３が後続する。バッファ５４００に更に含まれるものは、ＰＳＩブロック５４０４及びデータブロック５４０５である。図５４には、画像開始コード検出時点５４０６、画像開始コードの一部５４０７及び後続のＰフレーム５４０８も更に示されている。
【０３１４】
図５４の場合、これら２つのビデオパケットのみならず、これら２つのビデオパケット間の他のデータの全てのパケットもバッファリングされねばならない。該例では、画像開始コードが示されているが、同じ議論がシーケンスヘッダコードに対しても有効であることは明らかである。示された規準は、必要なバッファリングを１パケットのみに低減する。
【０３１５】
３つの定義された規準の１つが満たされたなら、対応するパケットが平文にされる。３つの規準の組み合わせの結果、しばしば、各フレーム境界において１つのみの平文パケットとなる。しかしながら、何らかのストリームに対する幾つかの実際的ケースでは、数個のパケットでもあり得る。事実、理論的に、これは多数のパケットでさえあり得る。
【０３１６】
第１の例は、ＧＯＰ当たり１ＰＥＳパケットで、例えば１２フレームのＧＯＰサイズのＩフレーム及びＰフレームのみからなるストリームである。なされた実験において、Ｉフレームの開始における平文パケットの数は常に１であった。Ｉフレームの終わりにおける、及び実際には全ての他のフレーム境界における平文パケットの数は通常は１であったが、時には２であった。Ｉフレームの開始において、ＰＥＳヘッダから画像コード拡張部までの全てのものは１パケット内である。他のフレーム境界における平文パケットは、画像開始コードから画像符号化拡張部の終わりまでの全データを含む。このデータは、２つのパケットにわたり分散させることができる。
【０３１７】
第２の例は、フレーム当たり１ＰＥＳパケットで、２から１２までの範囲の偶数値を持つ変化するＧＯＰサイズの、ＩＢＰ構造によるＩフレーム、Ｐフレーム及びＢフレームを有するようなストリームである。このストリームは、実際には、平文ストリームであるが、ここでは、暗号化されているかのように使用される。Ｉフレームの開始における平文パケットの数は殆どの場合２であり、Ｉフレームの終わり及び他のフレーム境界では常に１である。Ｉフレームの開始における上記２つのパケットは、主に、量子化テーブル及びシーケンスヘッダの存在によるものである。Ｉフレームの終わり及び他のフレーム境界において、ＰＥＳヘッダから画像符号化拡張部までのデータは全て１パケット内である。
【０３１８】
ＰＥＳ構造により、平文であるのはＩフレームの最後のパケットではなく、実際には次のフレームの最初のパケットであることに注意すべきである。これは、他の筋書きでも発生し得る。しかしながら、これは問題ではない。何故なら、この場合、Ｉフレームの最後のパケットはＩフレームデータのみを含み、除去される必要はないからである。
【０３１９】
また、実際には、前記３つの規準の組み合わせが各フレーム境界において１つの連続した平文ビデオ領域になることにも注意すべきである。理論的に、これが当てはまる必要はない。規準２及び３の組み合わせは、常に、連続した領域となるが、理論的に平文ＰＥＳヘッダ領域は別のものとすることができる。
【０３２０】
以下においては、ハイブリッドストリームにおいて必要な情報を如何にして見つけるかを説明する。
【０３２１】
実際には、各フレーム境界に１つの連続した平文領域が存在する。Ｉフレーム（ＧＯＰ）の開始部において、該平文領域はＰＥＳヘッダの最初のバイトから少なくとも画像符号化拡張部の最後のバイトまで続く。
【０３２２】
一例が図５５に示される。
【０３２３】
図５５は、Ｉフレームの開始部における実際的な平文領域を示す。図５５に示されるデータシーケンスは、ＰＥＳヘッダ５５００、シーケンスヘッダ５５０１、シーケンス拡張部５５０２、ＧＯＰヘッダ５５０３、画像開始コード５５０４、画像ヘッダ５５０５、他の画像ヘッダ５５０６、画像符号化拡張部５５０７、及びＩフレームデータ５５０８を含む。
【０３２４】
構成成分５５００〜５５０５は第１のＩフレームパケット５５０９に関するもので、構成成分５５０６〜５５０８は第２のＩフレームパケット５５１０に関するものである。
【０３２５】
全ての必要なデータは、この領域内にあり、当該ストリームのPLUSIにより印されたパケットで開始する該部分を解析することにより容易に見つけることができる。
【０３２６】
Ｉフレームの終了部では、２つの可能性がある：
１．フレーム当たり１ＰＥＳパケットの場合、Ｉフレームの終了部（の後の）平文領域のエッジもＰＥＳヘッダの第１バイトで開始し、少なくとも画像符号化拡張部の最後のバイトまで延びる。全ての必要なデータは容易に見つかり、Ｉフレームの最後のパケットの削除（cleaning）は必要とされない（図５６の左側参照）。
２．ＧＯＰ当たり１ＰＥＳパケットの場合、Ｉフレームの終わりより後にはＰＥＳヘッダは存在しない。実際には、この位置にはシーケンスヘッダもない。この場合、画像開始コードの第４バイトから画像符号化拡張部の最後のバイトまでを含むパケットは、平文である（図５６の右側参照）。画像開始コードの４つのバイトは、例えば最初の３バイトが或るパケット内に、最後のバイトが次のパケット内のように、２つのパケットに渡って分散することができる。この場合、最初の３つのバイトは依然として暗号化されている。これは、この画像開始コードを検出することができないことを意味するように見える。
【０３２７】
図５６は、実際の平文領域を示す。図５６のシーケンスには、Ｉフレームの終わり５６００、PLUSIプレゼント５６０１、ＰＥＳヘッダ５６０２、画像開始コード５６０３、画像ヘッダ５６０４、画像符号化拡張部５６０５、Ｐフレーム又はＢフレームデータ５６０６、最後のＩフレームデータ５６０７、Ｉフレームの終わり５６０８、画像開始コード５６０９、画像ヘッダ５６１０、画像符号化拡張部５６１１、及びＰフレーム又はＢフレームデータ５６１２が示されている。
【０３２８】
実際に、各フレーム境界には平文領域が存在する。従って、Ｉフレームの終了部の検出は、Ｉフレームのものより後の最初の画像開始コードの検索を意味する。暗号化されたデータにおける誤った肯定的合致を回避するために、このコードに関して平文ビデオパケットのみが検索されるべきであることは明らかであろう。パケットのペイロードが平文であるか否かは、パケットヘッダにおけるスクランブル制御ビットにより示される。検出は、４つのバイトの所与のシーケンス（0x00 0x00 0x01 0x00）が見つかった場合にのみ肯定的合致を示す。該シーケンスは、フレームのタイプを無視した画像開始コードに対応する。残念ながら、画像開始コードは、トランスポートストリームパケットの境界上に整列される必要はない。これは、画像開始コードが２つのパケットにわたって分散されたとしたら、これらパケットのうちの第２のものだけが平文であろうことを意味する。
【０３２９】
これが、図５７に示されている。
【０３３０】
問題は、符号５７００により示された２つの部分が、誤った肯定的合致を与えるかである。図５７において、パケットヘッダは符号５７０１により示され、平文のパケットペイロードは符号５７０２により示され、暗号化されたパケットペイロードは符号５７０３により示されている。
【０３３１】
一番上のライン５７０４は、完全に第２パケット内に位置する画像開始コードを示す。一番下のライン５７０５の場合、画像開始コードは完全に第１のパケット内にある。残りのライン５７０６は、分散された画像開始コードの３つの可能性を示す。
【０３３２】
部分的に暗号化された画像開始コードを検出することは不可能であると予測されるかも知れない。しかしながら、このジレンマから抜け出す方法がある。各平文領域は、画像開始コード又は少なくともその最後のバイトを含まなければならない。従って、或る平文領域において画像開始コードが見つからない場合、この領域は画像開始コードの最後のバイトの幾つかで開始している筈であることがわかる。このバイト数は、図５７に示すように、１、２又は３である。実際に、どれだけ多くのバイトが存在するかを正確に検出することが可能である。この点に関しては、画像符号化タイプの３つのビットが全てゼロであることは決してあり得ないことに注意することが重要である。何故なら、これはＭＰＥＧ２規格により禁止されているからである。従って、図５７に0xYYにより示された画像開始コードの第2バイトは決して0x00にはなり得ない。従って、当該平文領域が0x00 0x01 0x00で開始した場合、これらは画像開始コードの最後の3バイトである。該領域が0x01 0x00で開始した場合、これらは最後の2バイトである。該領域が0x00 0x01 0x00ではなく、0x00で開始した場合、最後のバイトのみが存在する。このようにして、何処に画像開始コードが位置するかが正確に分かり、これに続くデータを解析することができる。もし必要又は望むなら、画像タイプはバイト0xYYから読み取ることができる。
【０３３３】
また、画像開始コードが２つのパケットに渡って分散されている場合、Ｉフレームの最後のパケットを全ての非Ｉフレームデータを削除することにより除去することは可能ではなさそうだと言うこともできる。これは、実際に正しい。何故なら、画像開始コードの暗号化された部分を削除することは可能ではないからである。しかしながら、トリックプレイストリームの構築においては、空のＰフレームがＩフレームの最後に付加されるであろう。この空Ｐフレームは画像開始コードで始まるであろう。従って、画像開始コードの暗号化されたバイトは再使用することができる。何故なら、これらのバイトのいくつが、最後の暗号化されたパケットの終了部に存在するかが分かるからである。この数のバイトは、Ｉフレームの後に追加されるべき最初の空Ｐフレームの画像開始コードから削除される。
【０３３４】
図５８は、このような状況の一例を示す。
【０３３５】
図５８には、部分的に暗号化された画像開始コードに付加された空のＰフレームが示されている。画像開始コードは符号５８００により示されている。図５８には、時間基準５８０１も示されている。更に、画像符号化タイプが符号５８０２により示されている。空フレームのデータは符号５８０３により示されている。
【０３３６】
実際に予測されるべき状況を上述したが、理論的には幾つかの付加的状況が生じ得る。これは、平文ＰＥＳヘッダ領域と規準２及び３からの結果の平文領域とが、理論的に接続される必要がなく、暗号化されたビデオパケットにより分離され得るという事実から生じる。明瞭化のために、連続する平文領域とは、ビデオパケットのシーケンスは平文であるが、他の暗号化されたパケットが間に存在し得ることを意味することに言及すべきであろう。
【０３３７】
前記規準に従って、アクセスされるべき３つの重要なデータ領域が存在する：
１．ＰＥＳヘッダ領域；
２．シーケンスヘッダ及びシーケンス拡張部における情報；
３．画像開始コードから画像符号化拡張部までの情報。
【０３３８】
これら３つのデータ領域が図５９に示されている。
【０３３９】
図５９は、上記３つの規準に対応する平文データ領域を示す。第１の構成は、PLUSIプレゼント５９００及びＰＥＳヘッダ５９０１を示す。第２の画像は、シーケンスヘッダコード５９１０、シーケンスヘッダ５９１１、シーケンス拡張コード５９１２及びシーケンス拡張部５９１３を示す。画像開始コード５９１４が更に示されている。
【０３４０】
図５９における第３の画像は、画像開始コード５９２０、画像ヘッダ５９２１、画像符号化拡張コード５９２２及び画像符号化拡張部５９２３を示している。
【０３４１】
このデータを位置特定すると共に正しく受け渡すために、当該ストリームにおいて３つの項目が見つけられなければならない：
１．パケットヘッダにおけるPLUSIビット；
２．シーケンスヘッダコード（0x00 0x00 0x01 0xB3）；
３．画像開始コード（0x00 0x00 0x01 0x00）。
【０３４２】
項目１を見つけることは、単にPLUSIビット及びパケットヘッダを探すだけで容易であり、これが１に設定されていたら、パケットはＰＥＳヘッダで開始し、次いでこれを渡すことができる。項目２及び３に関する状況は、もっと複雑である。何故なら、シーケンスヘッダコード及び画像開始コードは２つのパケットにわたって分散され、結果として部分的に暗号化されたコードである可能性があるからである。従って、これらコードの直接的検出は、データの何らかの喪失につながる。しかしながら、この問題に対する解決策が存在する。ＭＰＥＧ２においては、シーケンス拡張部及び画像符号化拡張部の存在は、図６０に示されるように、必須である。
【０３４３】
図６０は、ＭＰＥＧ２におけるヘッダ構造を示し、該構造は、シーケンスヘッダユニット６０００、シーケンス拡張ユニット６００１、拡張及びユーザユニット６００２、画像群ヘッダユニット６００３、ユーザユニット６００４、画像ヘッダユニット６００５、画像符号化拡張ユニット６００６、ユーザユニット６００７、画像データユニット６００８及びシーケンス終了ユニット６００９を含む。
【０３４４】
平文パケットに対する規準が形成された態様は、これら拡張部が完全に平文であることを保証することができる。これらは、先ず0x00 0x00 0x01 0xB5である拡張開始コードを検索することにより見つけることができる。次の４ビットは拡張開始コード識別子である。これらの４ビットは、シーケンス拡張部に対しては0001であり、画像符号化拡張部に対しては1000である。シーケンス拡張部が存在する場合、シーケンスヘッダコードも存在すべきであり、同様に、画像コード拡張部が存在するなら、画像開始コードも存在すべきである。この結果、下記のようになる：
− シーケンス拡張部が平文領域で見つかるが、シーケンスヘッダコードが同じ領域で見つからない場合、該シーケンスヘッダコードは２つのパケットにわたって分散されているべきであり、該シーケンスヘッダコードの最後のバイト又は複数のバイトは、可能性のあるＰＥＳヘッダを無視すると、この平文領域の最初のバイトである（シーケンスヘッダコード６１００、シーケンスヘッダ６１０１及びシーケンス拡張部６１０２を示す図６１参照）。
− 画像符号化拡張部が平文領域で見つかるが、画像開始コードが同じ領域で見つからない場合、該画像開始コードは２つのパケットにわたって分散されているべきであり、該画像開始コードの最後のバイト又は複数のバイトは、可能性のあるＰＥＳヘッダを無視すると、この平文領域の最初のバイトである（画像開始コード６２００、画像ヘッダ６２０１及び画像符号化拡張部６２０２を示す図６２参照）。
【０３４５】
これらの２つの状況は、１つの平文領域においては決して同時に発生し得ないことに注意すべきである。シーケンス拡張部及び画像符号化拡張部が共に存在する場合、これらの２つの間に位置される画像開始コードは必然的に完全に平文であろう。この場合、シーケンスヘッダコードのみが部分的に暗号化されている可能性がある。勿論、シーケンスヘッダコード又は画像開始コードが完全に平文であり、従って素直な態様で検出される場合、対応するデータの受け渡しは即座に開始することができる。しかしながら、上述した状況の一方に遭遇した場合、正しい受け渡しを開始することができる前に、これらコードのうちのどれだけ多くのバイトが当該平文領域の開始部に又はＰＥＳヘッダの後にあるかが先ず分からねばならない。画像開始コードに関してこれを検出する方法は、シーケンスヘッダコードに対しても適用することができる。
【０３４６】
図６３は、２つのパケットにわたって分散されたシーケンスヘッダコードを示す。
【０３４７】
シーケンスヘッダコードに対する状況が、図６３に示されている。平文は、4番目のバイトから以降にのみ保証される。このバイトは、0x00 0x00 0x01 0xB3に等しいシーケンスヘッダコードの最後のバイトである。従って、シーケンスヘッダコードは存在するが、この領域では検出されない場合、該コードの最後のバイトの幾つかは、この領域の開始部に又はＰＥＳヘッダの後に存在しなければならない。画像開始コードと同様に、これらバイトのうちの幾つが存在するかを正確に検出することができる。検出は、ＰＥＳヘッダを無視して、当該領域における最初の平文バイトで開始する。最初のバイトが0x00 0x01 0xB3なら、3バイトが存在し、これらが0x01 0xB3なら、２バイトが存在し、最初のバイトが0xB3なら、この１バイトのみが存在する。該バイト数、従ってシーケンスヘッダコードの最後のバイトの位置が分かれば、画像開始コードが、このコードに続くデータの正しい受け渡しを可能にする。
【０３４８】
当該明細書で使用される略語のリストが表１に示される。
【表１】
【０３４９】
尚、上述した実施例は本発明を限定するというよりは解説するものであり、当業者であれば添付請求項に記載した本発明の範囲から逸脱することなしに多数の代替実施例を設計することができることに注意されたい。更に、上述した実施例の何れかは、例えば電池又は蓄積器等の内部電流供給部のような暗黙的特徴部を有するものである。また、請求項において、括弧内の如何なる符号も斯かる請求項を限定するものと見なしてはならない。また、"有する"等の用語は、如何なる請求項又は明細書全体に掲載されたもの以外の構成要素又はステップの存在を排除するものではない。また、単数形の構成要素は、複数の斯様な構成要素の存在を排除するものではなく、その逆でもある。幾つかの手段を列挙する装置の請求項において、これら手段の幾つかは１つの同一のハードウェア品目により具現化することができる。また、特定の手段が相互に異なる従属請求書で引用されるという単なる事実は、これら手段の組み合わせを有利に使用することができないということを示すものではない。また、文章を通して"データ"及び"コンテンツ"なる用語が入れ替え可能に使用されているが、これらは均等のものであると理解されたい。
【図面の簡単な説明】
【０３５０】
【図１】図１は、タイムスタンプ付きトランスポートストリームパケットを示す。
【図２】図２は、イントラ符号化フレーム及び順方向予測フレームを伴うＭＰＥＧ２画像群（グループ・オブ・ピクチャ）構造を示す。
【図３】図３は、イントラ符号化フレーム、順方向予測フレーム及び双方向予測フレームを伴うＭＰＥＧ２画像群構造を示す。
【図４】図４は、特徴点情報ファイルの構造及び記憶されたストリームコンテンツを示す。
【図５】図５は、平文ストリームに対するトリックプレイのためのシステムを示す。
【図６】図６は、トリックプレイにおける時間圧縮を示す。
【図７】図７は、分数距離によるトリックプレイを示す。
【図８】図８は、低速トリックプレイを示す。
【図９】図９は、一般的な条件付きアクセスシステムの構造を示す。
【図１０】図１０は、デジタルビデオ放送の暗号化されたトランスポートストリームパケットを示す。
【図１１】図１１は、図１０のデジタルビデオ放送暗号化トランスポートストリームパケットのトランスポートストリームパケットヘッダを示す。
【図１２】図１２は、完全に暗号化されたストリームに対してトリックプレイの実行を可能にするシステムを示す。
【図１３】図１３は、完全なトランスポートストリーム及び部分的トランスポートストリームを示す。
【図１４】図１４は、ストリームタイプＩ用及びストリームタイプII用の権限制御メッセージ（ＥＣＭ：Entitlement Control Message）を示す。
【図１５】図１５は、解読器への制御ワードの書込を示す。
【図１６】図１６は、高速順送りモードでの権限制御メッセージの処理を示す。
【図１７】図１７は、１つ又は２つの制御ワードの検出を示す。
【図１８】図１８は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図１９】図１９は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２０】図２０は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２１】図２１は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２２】図２２は、本発明の一実施例によるデータストリームを処理する方法を実行する間に得られるデータストリームを示す。
【図２３】図２３は、本発明の一実施例によるデータストリームを処理する装置を示す。
【図２４】図２４は、本発明の一実施例によるデータストリームを処理する他の装置を示す。
【図２５】図２５は、フレーム境界でのパケットの分割を示す。
【図２６】図２６は、通常プレイデータの解読の後のスロー順送り構成を示す。
【図２７】図２７は、各フレーム境界に平文パケットを伴う複合ストリームを示す。
【図２８】図２８は、記憶された複合ストリームに対するスロー順送り構成を示す。
【図２９】図２９は、連結点における不完全な画像開始コードを示す。
【図３０】図３０は、通常プレイにおける再配列の効果を示す。
【図３１】図３１は、スロー順送りモードでの再配列の効果を示す。
【図３２】図３２は、アンカフレームの前の空のＰフレームの挿入を示す。
【図３３】図３３は、逆方向予測空Ｂフレームの使用を示す。
【図３４】図３４は、順方向予測空Ｂフレームの使用を示す。
【図３５】図３５は、フレーム当たり１ＰＥＳパケットの場合のストリームの分割を示す。
【図３６】図３６は、ＰＥＳヘッダの開始部におけるストリームの分割を示す。
【図３７】図３７は、画像開始コードの開始部におけるストリームの分割を示す。
【図３８】図３８は、画像開始コード内でのストリームの分割を示す。
【図３９】図３９は、連結点における不完全な画像開始コードを示す。
【図４０】図４０は、ｎ＋ｍ＝４の例を示す。
【図４１】図４１は、ｎ＋ｍ＞４の例を示す。
【図４２】図４２は、ｎ＋ｍ＜４の例を示す。
【図４３】図４３は、ＤＴＳまでの変更されない距離を示す。
【図４４】図４４は、一連の同一のＢフレームの境界における等しいオフセットを示す。
【図４５】図４５は、Ｂフレームデータ長を示す。
【図４６】図４６は、Ｂフレームが１フレーム時間より大きい場合のデータの重なりを示す。
【図４７】図４７は、一様に分散されたパケットによるＢフレームの圧縮を示す。
【図４８】図４８は、空のフレームの配置を示す。
【図４９】図４９は、空のフレームの最初のパケットの配置を示す。
【図５０】図５０は、前のフレームに基づく空のフレームのパケット距離を示す。
【図５１】図５１は、１フレーム期間にわたって一様に分散された空フレームのパケットを示す。
【図５２】図５２は、複合ストリームへの変換のための位置を示す。
【図５３】図５３は、完全に暗号化された記録からの安全なトリックプレイの生成を示す。
【図５４】図５４は、完全に平文の画像開始コードに対するバッファリングの必要性を示す。
【図５５】図５５は、Ｉフレームの開始部における実際の平文領域を示す。
【図５６】図５６は、実際の平文領域を示す。
【図５７】図５７は、２つのパケットにわたって広がる画像開始コードを示す。
【図５８】図５８は、部分的に暗号化された画像開始コードに付属された空のＰフレームを示す。
【図５９】図５９は、３つの基準に対応する平文データ領域を示す。
【図６０】図６０は、ＭＰＥＧ２におけるヘッダ構造を示す。
【図６１】図６１は、シーケンスの拡張及びシーケンスヘッダコードを示す。
【図６２】図６２は、画像符号化の拡張及び画像開始コードを示す。
【図６３】図６３は、２つのパケットにわたって広がるシーケンスヘッダコードを示す。
【特許請求の範囲】
【請求項１】
データストリームを処理する装置であって、該装置が、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割する分割ユニットと、
分割されたフレームを、所定の複製レートに従って複数回複製する複製ユニットと、
前記複製された分割されたフレームを接続する接続ユニットと、
を有する装置。
【請求項２】
請求項１に記載の装置であって、暗号化されたデータストリームの隣接するフレームの間の暗号化されたフレーム境界部分を、前記解読されたフレーム境界部分により選択的に置換して、前記部分的に解読されたデータストリームを形成する解読ユニットを有するような装置。
【請求項３】
請求項２に記載の装置であって、前記解読ユニットが、暗号化されたデータストリームの隣接するフレームの間の前記暗号化されたフレーム境界部分のみを前記解読されたフレーム境界部分により選択的に置換すると共に、全ての他のフレーム部分を暗号化されたままに維持するように構成された装置。
【請求項４】
請求項２に記載の装置であって、前記解読ユニットが、前記暗号化されたフレーム境界部分を前記解読されたフレーム境界部分により選択的に置換して、前記部分的に解読されたデータストリームを、低減された又は最小の量の解読された部分を持つトリックプレイストリームを発生するための基礎として形成するような装置。
【請求項５】
請求項１に記載の装置であって、前記分割ユニットが、分割された各フレームの始めに平文パケットを挿入するよう構成されているような装置。
【請求項６】
請求項５に記載の装置であって、前記平文パケットがヘッダ及び／又はアダプテーションフィールドを有するような装置。
【請求項７】
請求項１に記載の装置であって、前記接続ユニットが、前記複製された分割されたフレームを、フレーム境界部分が２つのフレームに跨る位置を識別することに基づくと共に、これら識別された位置を補正することに基づいて接続するよう構成されているような装置。
【請求項８】
請求項１に記載の装置であって、前記接続ユニットが、前記分割されたフレームの前記フレーム境界部分の少なくとも一部のサイズを決定するように構成されると共に、前記分割されたフレームを該決定されたサイズに基づいて接続するように構成されている装置。
【請求項９】
請求項８に記載の装置であって、前記接続ユニットが、前記決定されたサイズが所定の閾値を超える場合に、前記フレーム境界部分の少なくとも一部のサイズを減少させるように構成されている装置。
【請求項１０】
請求項８に記載の装置であって、前記接続ユニットが、前記決定されたサイズが所定の閾値より小さい場合に、前記フレーム境界部分の少なくとも一部のサイズを増加させるように構成されている装置。
【請求項１１】
請求項１０に記載の装置であって、前記接続ユニットが、前記フレーム境界部分の少なくとも一部のサイズを、前記データストリームに追加部分を挿入することにより増加させるように構成されている装置。
【請求項１２】
請求項１に記載の装置であって、前記データストリームを記憶する記憶ユニットを有するような装置。
【請求項１３】
請求項１に記載の装置であって、完全に暗号化されたデータストリームを処理するように構成されている装置。
【請求項１４】
請求項１に記載の装置であって、イントラ符号化フレーム、順方向予測フレーム及び双方向予測フレームからなる群のうちの少なくとも１つのフレームを有するデータストリームを処理するように構成された装置。
【請求項１５】
請求項１に記載の装置であって、ビデオデータ又はオーディオデータのデータストリームを処理するように構成された装置。
【請求項１６】
請求項１に記載の装置であって、デジタルデータのデータストリームを処理するように構成された装置。
【請求項１７】
請求項１に記載の装置であって、処理された前記データストリームを再生する再生ユニットを有し、該再生ユニットが前記接続ユニットに接続されているような装置。
【請求項１８】
請求項１に記載の装置であって、前記データストリームをトリックプレイ再生モードで再生するように処理する発生ユニットを有するような装置。
【請求項１９】
請求項１８に記載の装置であって、前記トリックプレイ再生モードが、スロー順送り再生モード、スロー逆送り再生モード、静止再生モード、ステップ再生モード及び瞬時リプレイ再生モードからなる群のうちの１つであるような装置。
【請求項２０】
請求項１に記載の装置であって、ＭＰＥＧ２の暗号化されたデータストリームを処理するように構成された装置。
【請求項２１】
請求項１に記載の装置であって、
デジタルビデオ記録装置、
ネットワーク可能化装置、
条件付きアクセス装置、
携帯型オーディオプレーヤ、
携帯型ビデオプレーヤ、
携帯電話、
ＤＶＤプレーヤ、
ＣＤプレーヤ、
ハードディスク型メディアプレーヤ、
インターネットラジオ装置、
コンピュータ、
テレビジョン装置、
公衆娯楽装置、及び
ＭＰ３プレーヤ、
からなる群のうちの少なくとも１つとして実現された装置。
【請求項２２】
データストリームを処理する方法であって、該方法が、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を有する方法。
【請求項２３】
データストリームを処理するコンピュータプログラムが記憶されたコンピュータ読み取り可能な媒体であって、該コンピュータプログラムが、プロセッサにより実行された場合に、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を制御又は実行するよう構成されているようなコンピュータ読み取り可能な媒体。
【請求項２４】
データストリームを処理するプログラムエレメントであって、該プログラムエレメントが、プロセッサにより実行された場合に、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を制御又は実行するよう構成されているようなプログラムエレメント。
【請求項１】
データストリームを処理する装置であって、該装置が、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割する分割ユニットと、
分割されたフレームを、所定の複製レートに従って複数回複製する複製ユニットと、
前記複製された分割されたフレームを接続する接続ユニットと、
を有する装置。
【請求項２】
請求項１に記載の装置であって、暗号化されたデータストリームの隣接するフレームの間の暗号化されたフレーム境界部分を、前記解読されたフレーム境界部分により選択的に置換して、前記部分的に解読されたデータストリームを形成する解読ユニットを有するような装置。
【請求項３】
請求項２に記載の装置であって、前記解読ユニットが、暗号化されたデータストリームの隣接するフレームの間の前記暗号化されたフレーム境界部分のみを前記解読されたフレーム境界部分により選択的に置換すると共に、全ての他のフレーム部分を暗号化されたままに維持するように構成された装置。
【請求項４】
請求項２に記載の装置であって、前記解読ユニットが、前記暗号化されたフレーム境界部分を前記解読されたフレーム境界部分により選択的に置換して、前記部分的に解読されたデータストリームを、低減された又は最小の量の解読された部分を持つトリックプレイストリームを発生するための基礎として形成するような装置。
【請求項５】
請求項１に記載の装置であって、前記分割ユニットが、分割された各フレームの始めに平文パケットを挿入するよう構成されているような装置。
【請求項６】
請求項５に記載の装置であって、前記平文パケットがヘッダ及び／又はアダプテーションフィールドを有するような装置。
【請求項７】
請求項１に記載の装置であって、前記接続ユニットが、前記複製された分割されたフレームを、フレーム境界部分が２つのフレームに跨る位置を識別することに基づくと共に、これら識別された位置を補正することに基づいて接続するよう構成されているような装置。
【請求項８】
請求項１に記載の装置であって、前記接続ユニットが、前記分割されたフレームの前記フレーム境界部分の少なくとも一部のサイズを決定するように構成されると共に、前記分割されたフレームを該決定されたサイズに基づいて接続するように構成されている装置。
【請求項９】
請求項８に記載の装置であって、前記接続ユニットが、前記決定されたサイズが所定の閾値を超える場合に、前記フレーム境界部分の少なくとも一部のサイズを減少させるように構成されている装置。
【請求項１０】
請求項８に記載の装置であって、前記接続ユニットが、前記決定されたサイズが所定の閾値より小さい場合に、前記フレーム境界部分の少なくとも一部のサイズを増加させるように構成されている装置。
【請求項１１】
請求項１０に記載の装置であって、前記接続ユニットが、前記フレーム境界部分の少なくとも一部のサイズを、前記データストリームに追加部分を挿入することにより増加させるように構成されている装置。
【請求項１２】
請求項１に記載の装置であって、前記データストリームを記憶する記憶ユニットを有するような装置。
【請求項１３】
請求項１に記載の装置であって、完全に暗号化されたデータストリームを処理するように構成されている装置。
【請求項１４】
請求項１に記載の装置であって、イントラ符号化フレーム、順方向予測フレーム及び双方向予測フレームからなる群のうちの少なくとも１つのフレームを有するデータストリームを処理するように構成された装置。
【請求項１５】
請求項１に記載の装置であって、ビデオデータ又はオーディオデータのデータストリームを処理するように構成された装置。
【請求項１６】
請求項１に記載の装置であって、デジタルデータのデータストリームを処理するように構成された装置。
【請求項１７】
請求項１に記載の装置であって、処理された前記データストリームを再生する再生ユニットを有し、該再生ユニットが前記接続ユニットに接続されているような装置。
【請求項１８】
請求項１に記載の装置であって、前記データストリームをトリックプレイ再生モードで再生するように処理する発生ユニットを有するような装置。
【請求項１９】
請求項１８に記載の装置であって、前記トリックプレイ再生モードが、スロー順送り再生モード、スロー逆送り再生モード、静止再生モード、ステップ再生モード及び瞬時リプレイ再生モードからなる群のうちの１つであるような装置。
【請求項２０】
請求項１に記載の装置であって、ＭＰＥＧ２の暗号化されたデータストリームを処理するように構成された装置。
【請求項２１】
請求項１に記載の装置であって、
デジタルビデオ記録装置、
ネットワーク可能化装置、
条件付きアクセス装置、
携帯型オーディオプレーヤ、
携帯型ビデオプレーヤ、
携帯電話、
ＤＶＤプレーヤ、
ＣＤプレーヤ、
ハードディスク型メディアプレーヤ、
インターネットラジオ装置、
コンピュータ、
テレビジョン装置、
公衆娯楽装置、及び
ＭＰ３プレーヤ、
からなる群のうちの少なくとも１つとして実現された装置。
【請求項２２】
データストリームを処理する方法であって、該方法が、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を有する方法。
【請求項２３】
データストリームを処理するコンピュータプログラムが記憶されたコンピュータ読み取り可能な媒体であって、該コンピュータプログラムが、プロセッサにより実行された場合に、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を制御又は実行するよう構成されているようなコンピュータ読み取り可能な媒体。
【請求項２４】
データストリームを処理するプログラムエレメントであって、該プログラムエレメントが、プロセッサにより実行された場合に、
隣接するフレームの間に解読されたフレーム境界部分を有するような少なくとも部分的に解読されたデータストリームの隣接するフレームを、前記フレーム境界部分で分割するステップと、
分割されたフレームを、所定の複製レートに従って複数回複製するステップと、
前記複製された分割されたフレームを接続するステップと、
を制御又は実行するよう構成されているようなプログラムエレメント。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【公表番号】特表２００９−５２１１６３（Ｐ２００９−５２１１６３Ａ）
【公表日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願番号】特願２００８−５４６７０１（Ｐ２００８−５４６７０１）
【出願日】平成１８年１１月２８日（２００６．１１．２８）
【国際出願番号】ＰＣＴ／ＩＢ２００６／０５４４６９
【国際公開番号】ＷＯ２００７／０７２２４８
【国際公開日】平成１９年６月２８日（２００７．６．２８）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願日】平成１８年１１月２８日（２００６．１１．２８）
【国際出願番号】ＰＣＴ／ＩＢ２００６／０５４４６９
【国際公開番号】ＷＯ２００７／０７２２４８
【国際公開日】平成１９年６月２８日（２００７．６．２８）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]