JP4564753B2 - ビットストリームの変更方法及び装置 - Google Patents

Description

本発明は、ビットストリームを変更するビットストリームの変更方法、ビットストリームを変更するビットストリームの変更装置、元のビットストリームを復元するビットストリームの復元方法及び元のビットストリームを復元するビットストリームの復元装置に関する。

ビデオ、オーディオ、オーディオビジュアル及び／又は他の情報信号内に透かし模様を付与することが知られている。透かし模様は、その情報信号の出処及び／又はその情報信号の所有者又はそれ以外の関係者を確認するために設けられている。透かし模様は、視認可能又は隠蔽されたものであってもよい。本発明の好ましい実施の形態では、可視透かし模様を用いている。

また、画像を空間領域から変換領域、例えばウェーブレット（wavelet）領域に変換し、そのウェーブレット係数を変更することにより、画像に透かし模様を加えることも知られている。透かし模様を埋め込んだ変換領域画像は、後に空間領域に逆変換される。例えば、イノウエヒサシ等著、「ウェーブレット変換に基づく画像透かし模様法」、ＩＥＥＥ、０−７８０３−５４６７−２／９９を参照。

米国特許５８０９１３９号（Girod等）は、既に圧縮されたビデオ素材の隠蔽透かし模様法を開示している。ＭＰＥＧ２により圧縮されたビデオをエントロピー復号し、逆量子化してＤＣＴ係数を求める。スペクトル拡散された空間領域の透かし模様をＤＣＴ領域に変換し、変換された透かし模様を変換されたビデオのＤＣＴ係数に加える。透かし模様を加えても圧縮ビデオのビットレートが維持されるように、種々のステップが取られている。非ゼロ係数だけが変更される。また、符号化された透かし模様を加えた係数のビット数が透かし模様以前のその係数のビット数（加えて、前の符号化処理で節約されたその他余分なスペアビット数）と比較される。制御装置は、透かし模様を加えたビットストリームと元の透かし模様の入らないビットストリーム間の出力選択を制御する。透かし模様が入っていないエントロピー符号化係数がｎ０ビットを使い、且つ透かし模様入りエントロピー符号化係数がｎ１を使い、ｎ１＜ｎ０＋ｎ３の場合、透かし模様入り係数が出力される。ここで、ｎ３は使用可能となるスペアビットの数である。透かし模様はビデオデコーダ内で検出できるが、透かし模様埋込アルゴリズムを反転させることによっては、透かし模様入りビデオを元のビデオに復元することはできない。

ＷＯ９９／１０８３７号（Digimarc）は、画像を例えばＭＰＥＧ２を使って圧縮し、ＤＣＴ係数を変更して透かし模様を埋め込むビデオ画像透かし模様方法を開示している。そのビットレートは、係数の変更により増加したビットレート量を表すカウントがその変更により削減されたビットレート量より少なくするように維持することで、保持される。累積変更がプラス又はマイナスの限界値を超えると、それ以上の変更はなされない。その透かし模様はビデオデコーダ内で検出できるが、その透かし模様アルゴリズムを反転させることによっては、透かし模様を埋め込んだビデオを元のビデオに復元することはできない。

ＵＳ−Ａ−５８０９１３９及びＷＯ９９／１０８３７の両者は共に、ビットレートを監視する手段と、一定の限界値に達した場合に、透かし模様埋込み処理を止める手段とを必要とする。ＵＳ−Ａ−５８０９１３９及びＷＯ９９／１０８３７では、それは、結果的には画像内に透かし模様をランダムに分散することになる。これらの提案は、画像内にメッセージを表すデータを埋め込む不可逆的非視認透かし模様を狙ったものである。

これは、圧縮符号化情報信号、特に圧縮符号化画像信号に対して知られている。更に、情報信号にデータを付加する情報信号に対する変更がなされると、その圧縮は通常非効率的になる。圧縮情報信号を表すビット数への変更を最小限にして、例えば画像内で確認できるような、伸長された情報信号内で視認可能である情報信号の変更を生成できるような圧縮情報信号の処理が望ましい。

本願と共に係属中の先の出願であるＥＰ０１３１０１１３．４（ＵＳＳＮ１０・００６０５０）は、圧縮ビデオビットストリームの変更及び透かし模様をそれから取り外す方法及び装置の一例である。ビットストリーム上で実行される圧縮処理には、ＤＣＴ係数を使用する。その変更処理は、透かし模様処理されたビットストリームが、その透かし模様処理される前のビットストリーム以上のビットを持たないように、したがって確実に同じビットレートを有するように実行される。ＤＣＴ係数を表すコードの固定長部分を、その固定長コードにおけるビット数を増やさずに暗号化することによりなされる。その最も好ましい実施の形態は、Ｉフレームの圧縮ビットストリームであり、しかも可視透かし模様生成に関して、その手法はそのようなビットストリームに適している。その手法は、他の圧縮ビットストリームに適用できるが、表示された画像内の透かし模様の視認性は、ビット数を増やさないとの制限から希望通りのものではない。

ＭＰＥＧ２は周知であり、ＩＳＯ／ＩＥＣ／１３８１８に定義されている。

本発明は、ビデオ、オーディオ、オーディオビジュアル又は他の情報信号を含むビットストリームに適用可能であり、変更を生成するものであって、情報信号の、好ましくはビットレートを変更せずに、取り外し可能及び視認可能な変更で、及び好ましくはビットレートを変更しない技術を提供することを目的とする。本発明の一実施の形態は、圧縮ビットストリーム（例えばＭＰＥＧ２）に適用可能であり、同時に圧縮ビットストリーム内のビットレートを変更せずに、変更がビットストリームから取り外し可能であるような、所望の視認性を有する変更を生成できる変更技術を提供しようとするものである。

本発明は、ピクチャ情報を表すデジタルコードを含むビットストリームを変更するビットストリームの変更方法を提供する。このビットストリームの変更方法は、透かし模様を埋め込むピクチャの該透かし模様の部分に対応するデジタルコードであって、上記ピクチャ情報の変更を表す少なくとも１つの変更コードが含まれることになる上記ビットストリームの一部分を占める少なくとも１つのデジタルコードを選択するステップと、上記ビットストリームの一部分から、上記選択されたデジタルコードを取り外すステップと、上記選択されたデジタルコードの代わりに、上記少なくとも１つの変更コードを、上記ビットストリームの一部分に挿入するステップとを有する。上記選択され、取り外されたデジタルコードのビット数は、上記ビットストリームに挿入された変更コードのビット数以上である。そして、このビットストリームの変更方法は、（１）上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて格納するステップと、（２）上記選択され、取り外されたデジタルコードを、上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置するステップとのうちの少なくとも一方を更に有する。

上記変更が、上記ビットストリームにより表される情報内において視認可能とすることが好ましい。

本発明の各実施の形態における変更とは、ビットストリーム内のビットを隠蔽するのではなくむしろ、ビットストリームにより表される情報において視認可能な変更を提供するものである。

このような方法によれば、変更されたビットストリームのビットレートは元のビットストリーム（以下、原ビットストリームともいう）のそれと同じに保持される。変更コードの追加では追加データが生成される。原コードを取り外し、ビットストリームの最後に、それらを付加することにより、ビットストリーム内のデータ量は増やさないで済む。原コードを取り除くことにより生ずるビットストリーム内の空きスペースは変更ユーザデータフィールドとして、原コードの少なくとも一部のために使用できる。また、このフィールドに収めることのできなかったコードは、ビットストリームの終わりに付加する。コードは、ビットストリームの開始端又はその最終端に付加してもよい。

コードは別のファイルにおいてもよく、又はビットストリームの開始端又は最終端に付加されるファイル中に置いてもよい。

本発明の好ましい実施の形態におけるビットストリームは、ＭＰＥＧ２規格により圧縮されたビットストリームであることが好ましい。ＭＰＥＧ２規格においてはビットストリームのビットレートがその規格に準拠することが特に重要である。そこで、本発明では、変更コードを加えてもＭＰＥＧ２ビットストリームがその規格に準拠できるようにし、その変更処理から生ずる余剰なデータを、ＭＰＥＧ２規格に準拠したビットストリーム内に置かず、付加させるようにした。余剰データとはビットストリーム内の変更ユーザデータフィールドに置くことのできなかったデータのことである。

本発明の好ましい実施の形態によれば、変更データの取外しと原ビットストリームの復元ができるように、全ての原データの保存を可能としている。（これは勿論、変更されたビットストリームのその他の処理、例えばノイズのあるチャンネルを介した送信、又は変更信号が後段処理により失われないと仮定してのことである。）
本発明は、ピクチャ情報を表すデジタルコードを含むビットストリームを変更するビットストリームの変更装置を提供する。このビットストリームの変更装置は、透かし模様を埋め込むピクチャの該透かし模様の部分に対応するデジタルコードであって、上記ピクチャ情報内で視認可能な変更を表す少なくとも１つの変更コードが含まれることになる上記ビットストリームの一部分を占有する少なくとも１つのデジタルコードを選択する選択手段と、上記ビットストリームの一部分から、上記選択されたデジタルコードを取り外す取外し手段と、上記選択されたデジタルコードの代わりに、上記変更コードを、上記ビットストリームの一部分に配置する変更コード配置手段とを備える。上記選択され、取り外されたデジタルコードのビット数は、上記ビットストリームに配置された変更コードのビット数以上である。そして、このビットストリームの変更装置は、（１）上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて格納し、及び／又は（２）上記選択され、取り外されたデジタルコードを上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置する取外しコード配置手段を更に備える。

本発明の一実施の形態においては、上記ビットストリームは情報信号の変換係数、例えばＤＣ及びＡＣ係数を含むＤＣＴ係数を表すデジタルコードを備えている。本発明の一例においては、上記ビットストリームを変更するための種々の手法を用いられる。それらの手法には（１）ＡＣ係数の取外しと（２）ＤＣ係数の取外しとが含まれる。取り外された係数は変更コードで置換される。変更されたビットストリームのビット数に及ぼす各種手法の効果を評価し、該評価に応じてビットストリームを実際に変更するための１つ以上の手法がその中から選択される。これにより変更ビットストリームのビットレートを原ビットストリームのそれに等しく保持できる手法が選択できる。

原ビットストリームは動きベクトルを表すコードを含むインター符号化ピクチャ（inter-encoded picture）を含んでいてもよい。上記変更が画像内で可視透かし模様を表す場合、上記動きベクトルは透かし模様を歪ませてしまう。本発明の一実施の形態では、少なくとも１つの変更コードを含むことになるビットストリームの該当部分と関連付けて動きベクトルコードを取り除くステップと、ゼロ動きベクトルを表す動きベクトル変更コードで原動きベクトルコードを置換するステップと、該取り外された動きベクトルコードを上記ビットストリームの最後に置くか又は上記ビットストリーム内の取り外されたコードのデータフィールドに置くステップとを含む。本例によれば、透かし模様の変形を提言することができる。

ＭＰＥＧ２ビットストリームは、符号化のタイプを示すタイプコードを使ってフィールドタイプ又はフレームタイプで符号化されたＤＣＴブロックを含んでもよい。１つのフィールドタイプのＤＣＴブロックは変更を受けるが隣接したフィールドタイプのブロックが変更を受けていない場合、その透かし模様はストライプ状に歪むことが知られている。そこで、本発明の一実施の形態では、フィールドタイプを示す該タイプコードの１つを選択して取り外し、フレームタイプを示す変更タイプコードでその取り外されたタイプコードを置換し、該取り外されたタイプコードを（１）上記ビットストリームの最後か、（２）上記ビットストリーム内の１つ以上の取り外されたコードのデータフィールド内のうち、いずれか又はその両方に格納する。

本発明は、元のビットストリームを復元するビットストリームの復元方法を提供する。このビットストリームの復元方法は、上記元のビットストリームの選択された部分であって、元のコードが取り外された部分に、変更コードを有し、該取り外された元のビットストリームが、該元のビットストリームの変更ユーザデータ部分に配置されるとともに、該元のビットストリームの最後に付加された変更ビットストリームを受け取るステップと、上記変更ビットストリームを構文解析するステップと、上記元のコードを格納するステップと、上記変更コードを上記格納された元のコードで置換するステップとを有する。

本発明は、元のビットストリームを復元するビットストリームの復元装置を提供する。このビットストリームの復元装置は、上記元のビットストリームの選択された部分であって、元のコードが取り外された部分に、変更コードを有し、該取り外された元のコードが、該元のビットストリームの変更ユーザデータ部分に配置されるとともに、該元のビットストリームの最後に付加された変更ビットストリームを受け取る受取り手段と、上記変更ビットストリームを構文解析する構文解析手段と、上記元のコードを格納する記憶手段と、上記変更コードを、上記格納された元のコードで置換する置換手段とを備える。

本発明の他の実施の形態は、注視されるべき特許請求の範囲において具体的に示される。

本発明がより良く理解されるために、及び本発明がどのようにして効果を奏するかを示すために、例として、以下の添付された図面を参照して説明する。

以下の説明では、ＭＰＥＧ２圧縮されたビットストリームが変更される。この変更は、透かし模様（Watermark）と呼ぶ。この透かし模様をビットストリームに適用することを埋込み（embedding）と呼ぶ。原ビットストリームを復元することを洗浄（washing）と呼ぶ。

第１の実施の形態
本発明の第１の実施の形態について説明する。説明を容易にするために、この実施の形態においては、音声の付かない単独のストリームであるＭＰＥＧ２ビデオビットストリーム、すなわちＭＰＥＧ２ビデオシーケンスファイルのＩフレーム中に透かし模様データを配置することについて説明する。なお、ビットストリームは、パケット化されたビットストリームであってもよい。もちろん、本発明は、Ｉフレームに限定されるものではなく、ビデオ又はＭＰＥＧ２に限定されるものでもない。更に、説明を容易にするために、以下の説明では輝度情報のみについて言及するが、本発明は、輝度情報に限定されるものではない。

最初に、ＭＰＥＧ２について説明する。図１に画像フレーム２を示す。画像は、デジタル画素により表される。図２に示すように、８ｘ８画素のブロック４が選択されて、図３に示すように、これらのブロック４は、離散コサイン変換（ＤＣＴ）にかけられて、８ｘ８ＤＣＴ係数を含むＤＣＴブロックを形成する。係数はＤＣ係数６とＡＣ係数７とを含む。連続ビットストリームを形成するために、図３に示すように、係数はジグザグ走査パターン８で走査される（他のパターンも知られている）。図４に示すように、４つの隣接するＤＣＴブロックのグループがマクロブロック１０としてグループ化される。図５に示すように、画像フレームは、マクロブロックの行Ｒ１、Ｒ２、Ｒ３等として構成される。マクロブロックは、スライス１２に構成される。１つのスライス１２は、マクロブロックの水平方向の集合である。新たなスライス１２は、マクロブロックの各行の最初から開始する。１つのスライス１２には任意の数のマクロブロックが含まれる。一行のマクロブロックには任意の数のスライス１２が含まれる。

図６において、ＭＰＥＧ２は、以下のタイプのフレームを有する。Ｉフレームは、イントラ符号化フレームであって、他のフレームを参照せずに、そのフレーム内に全ての画像データが含まれているフレームである。Ｐフレームは、前方のＩフレーム又はＢフレームから動き補償予測を用いて符号化されるフレームである。Ｂフレームは、前方の及び／又は後方のＩフレーム又はＰフレームから動き補償予測を用いて符号化されるフレームである。説明を容易にするために、第１の実施の形態の以下の説明ではＩフレームだけについて言及する。

フレームは、ＧＯＰと呼ばれる画像グループに纏められている。図６は、Ｉ、Ｂ、Ｂ及びＰフレームの列の繰り返しがＧＯＰを形成する代表的なＧＯＰの一部を示す。他の列も可能である。一般的なＧＯＰ内のフレーム数は、１２又は１５であるが、他のフレーム数も可能である。

図７及び図１１は、ここで所謂ピクチャデータと呼ぶもののデータフォーマットを示す。このピクチャデータは、ピクチャスタートコード間の全てのデータを含み、その中にはヘッダ（ＨＤＲ）と、ユーザデータ（ＵＤ）と、画像の１フレームを表すピクチャデータ１６とが含まれる。ＭＰＥＧ２では、ユーザデータ（ＵＤ）をピクチャデータ内のピクチャデータ１６の前に置くことが許可されている。ユーザデータＵＤのフィールドは無くても、又は１つ以上のユーザデータフィールドが存在してもよい。

ＤＣＴブロック及びマクロブロックは、ピクチャデータ１６内で、図８に示すように、フォーマットされている。各ＤＣＴブロックは、ＤＣ係数とそれに続くＡＣ係数を含む。ＤＣＴブロック間は、ブロックエンドコードＥＯＢで分離されている。

Ｉフレームにおいて、ＤＣ係数は、差分に基づき符号化される（differentially encoded）。その差分値（differential values）は、ここではＤＣ差分と呼ぶ。ＡＣ係数は、ランレングス（run length）符号化され、可変長コード（ＶＬＣ）で表され、ここではＡＣ ＶＬＣと呼ぶ。

ＭＰＥＧ２符号化処理は、ＭＰＥＧ２規格に準拠する全てのデコーダで復号可能であるビットストリームを生成しなければならない。ビットストリームはバッファ内で復号されるように、デコーダは、ビットストリームを一時的に格納するバッファを備える。ＭＰＥＧ２規格は、そのバッファのサイズを定義している。一般に、バッファは、アンダフローも、データが失われないようにオーバフローもしないように構成されている（ある特定の条件の下ではアンダフローは許容される）。符号化処理は、アンダフロー及びオーバフローを起こさないように、そのビットレートを制限して行われる。

この実施の形態において、ビットストリームに可視透かし模様を加える目的で、符号化ビットストリームを変更することにより、ビットレートを変える危険があり、したがってアンダフローやオーバフローを起こす危険がある。以下に説明するこの実施の形態では、ピクチャデータのビットレートを変えずに、したがってバッファをアンダフロー又はオーバフローさせずに、ビットストリームに可視透かし模様を加え、且つその透かし模様を除去して原画像を復元することを目的とする。

図９に示すように、テンプレート１８は、透かし模様を定義する。図９の実施の形態において、透かし模様は、ＳｏｎｙのＳの字になっているが、透かし模様はどのような形状であってもよい。テンプレート１８は、透かし模様をＤＣＴブロックの解像度で定義する。テンプレートについては、後述の「テンプレート」の項で更に説明する。

図１０に示すように、本発明の第１の実施の形態は概略以下のように動作する。これらの動作は、この実施の形態においてはＩフレームについてのみ行われるが、本発明はＩフレーム上の動作に限られるものではない。

ステップＳ２において、「透かし模様Ｓ内に存在する」マクロブロックが選択され、「これらのマクロブロック」の全てのＤＣ差分及びＡＣ ＶＬＣが取り出され、ステップＳ４において、格納される。

ステップＳ６において、透かし模様を表す新たなＤＣ差分が、取り出されたＤＣ差分の代わり、テンプレートマクロブロックのブロック内に挿入される（ＡＣ ＶＬＣは、これらのブロック内で置換されない）。Ｉフレーム内のＤＣ係数は、差分に基づき符号化される。このため、新たなＤＣ差分も（詳細は後述）、テンプレートの端部では、空間的に前のマクロブロック及び後のマクロブロックに依存して計算する必要がある。

ステップＳ８において、元の原ＤＣ差分及びＡＣ ＶＬＳを取り除くことにより、Ｉフレームから取り出されたビット数Ｎｒが確認され、新たなＤＣ差分によりＩフレームに加えられるビット数Ｎａが決定される。Ｎｒ−Ｎａの差がピクチャデータ１６内における空きのデータスペースの量を示す。そのスペースが閾値（ＭＰＥＧ２の場合５バイト）を超えると、図１１Ｂに示すように、可視透かし模様ユーザデータスペース（以下、単にユーザデータスペースともいう）２０がピクチャデータ１６内に生成される。少なくとも幾つかの格納されたＤＣ差分及びＡＣ ＶＬＣは、そのユーザデータスペース２０内に置かれる。ピクチャデータ１６のビットレートが変更されないことを確実にするために、ゼロパディング（zero padding）２２をピクチャデータ１６に加えてもよい。ユーザデータスペース２０を生成するのに利用できる十分な空きスペースがない場合には、ゼロパディング２２が加えられる。ユーザデータスペース２０に置かれた係数は、ユーザデータスペース２０に置かれる前に暗号化されており、承認された人だけが原画像を再構築することができる。

上述の処理は、ビデオシーケンス内のＩフレーム毎に繰り返される（ステップＳ１０）。図１４においてビデオシーケンスの一部が示される。説明を簡単にするために、図１４では、Ｉフレームだけが示されている。ピクチャデータフレームは、説明を容易にするために、単純化された形態で示されている。シーケンスがＰ及び／又はＢフレームを含む場合、このようなフレームによって、Ｉフレームは分離されることになる。シーケンスの第１のＩフレームＰ１は、透かし模様ユーザデータスペース２０を含み、透かし模様ユーザデータスペース２０は、フレームＰ１の取り出された係数の幾つかを含む。フレームＰ２は、ユーザデータスペース２０を有し、フレームＰ１から取り出された他の係数がそのユーザデータスペース２０に置かれる。図１４の実施の形態において、フレームＰ２のユーザデータスペース２０は、フレームＰ２の取り出された係数の幾つかを収容する容量がある。フレームＰ２の取り出された他の係数は、フレームＰ３のユーザデータスペース２０に置かれる。フレームＰ４は、ユーザデータスペース２０に対する余分な容量が無いように示されており、フレームＰ３から取り出された係数の幾つかは、フレームＰ５のユーザデータスペース２０に置かれる。したがって、図１４に示すように、ビデオシーケンスのフレームのピクチャデータ１６のスペースから一連の順序で取り出された係数は、記憶装置から取り出され、暗号化されて、ピクチャデータのフレーム内に生成された透かし模様ユーザデータスペース２０に、同じ一連の順序で、ピクチャデータのビットレートを増やさずに配置される。ビデオシーケンスの終わりは、シーケンスエンドコード２６により示される。

ビデオシーケンスに生成されたユーザデータスペースは、取り外した全ての係数を収容する十分な空き容量を提供できない場合がある。そこで、図１０のステップＳ１２に示すように、残りの係数は、記憶装置から取り出され、暗号化されて、図１４の符号２８で示すように、ビデオシーケンスの最後のシーケンスエンドコード２６の後に付加される。ＭＰＥＧ２ビットストリームの最後に付加されたデータは、ＭＰＥＧ２ビットストリームの一部であるが、ピクチャスタートコードが先行しない。このため、付加されたデータは、ＭＰＥＧ２デコーダにより無視される。

上述のように、この実施の形態の処理について、Ｉフレームだけに関して説明したが、ビデオシーケンスは、通常、Ｐフレーム及びＢフレームも含んでいる。幾つかのＰ及びＢフレームは、ゼロパディングを含んでもよい。この場合、ゼロパディングを取り外して、透かし模様ユーザデータスペース（以下、ユーザデータブロックともいう）用に使用してもよく、取り外した原係数をユーザデータブロックに置くことができる。このようなゼロパディングは、原ビットストリームを復元中に元に戻される。

以上の概要では、一部動作についてその詳細が省略されている。以下では、それらについて説明する。

ブロックエンド（End of Block）及び他のコード
図１３で最もよく示されているが、ピクチャデータ１６から取り出された原データ３０（ＤＣ差分及びＡＣ ＶＬＣ）には、元の（又はそのコピーの）ブロックエンドコードＥＯＢが含まれている。ピクチャデータ１６に加えられたデータ３２（すなわち新たなＤＣ差分）には新たな（又は元の）ブロックエンドコードＥＯＢが含まれている。更に、新たに生成された透かし模様ユーザデータスペース２０には、ユーザデータスタートコード３４が含まれているが、これは、ピクチャデータフレーム内のビット数を増加させる。一旦、原ＡＣ ＶＬＣ及びＤＣ差分が取り出された後、ピクチャデータフレーム内で利用できる余分な容量を決定する場合、ブロックエンドコードＥＯＢが残っているので、ＤＣ差分とＡＣ可変長コード（ＶＬＣ）だけが含まれることになる。

透かし模様ユーザデータブロックのフラグ設定
図１２において、透かし模様処理により挿入される透かし模様ユーザデータブロック２０を元から存在する全てのユーザデータブロックから区別できるようにする必要がある。この目的のために、以下の手法が用いられる。

ピクチャフレームが原ユーザデータブロック３６を含むか含まないかに拘らず、透かし模様ユーザデータブロック２０を収容するスペースがピクチャフレーム内にある場合、透かし模様ユーザデータブロック２０がピクチャフレーム内の最後のユーザデータブロックとなる（図１２（ｂ）を参照）。透かし模様ユーザデータの最後のバイトの最終ビット３８は、「１」に設定される（すなわち、ユーザデータ内の最後のバイトまで全バイト数を送信し、次に透かし模様データの７ビットだけと、それに続く単一の「１」ビットを送信する）。

図１２（ｃ）に示すように、画像が１つ以上の原ユーザデータブロック３６を含み、その画像内に透かし模様ユーザデータブロックを収容するスペースがない場合、ユーザデータの最後のブロックの最後のバイトの最終ビット４０は、透かし模様データに格納されて「０」に置換される。

画像が原ユーザデータブロックを含まず、透かし模様ユーザデータブロックを収めるスペースが画像内にない場合には、操作は不要である。

上述のように最終ビットを変更することは単なる一例である。代わりに、最初のビットを変えてもよい。

透かし模様データの暗号化、図１５
透かし模様が埋め込まれたＭＰＥＧ２ファイル中に現れる透かし模様データは、ＭＰＥＧスタートコードを含んではならない。ＭＰＥＧスタートコードは、ユーザデータ領域を途中で終了させたり、又はデコーダの他の好ましくない動作の原因となるからである。ＤＣ差分及びＡＣ ＶＬＣを表すのに使用されるコードの特性としては、表示画像データ内でスタートコードが誤って発生されるものであってはならない。したがって、透かし模様データ内でもそれらが発生してはならず、フラグ情報を発生する際には注意が必要である。しかしながら、透かし模様の暗号化の結果としてスタートコードが生成される場合がある。したがって、暗号化されたデータをスタートコードと対比してチェックする必要があり、それが発生する場合には、暗号化されていない透かし模様データに戻す必要がある（これは、正規の鍵を使って復号するとき、どのバイトが暗号化されずに残っているかを決めることができるだけなので、安全性には影響を及ぼさない）。暗号化されない透かし模様データに戻す必要がある場合には、結果的に暗号化データ／非暗号化データの境界線上で別のスタートコードの生成がなかったかどうかのチェックも行わなければならない。

任意の適切な暗号化アルゴリズムを使ってもよい。現状ではＡＥＳアルゴリズムが好ましい。

図１５は、排他的論理和（ＸＯＲ）演算を使った暗号化処理を説明するフローチャートを示す。ＸＯＲ演算が使われるので、復号処理は暗号化処理と同じである。

図１５において、
「ｉｄｘ」は、暗号化される（又は復号される）透かし模様データバイトを割り出すインデックスカウントである。
「ｚｅｒｏ＿ｃｏｕｎｔ」は、ビットストリーム内の連続するゼロのカウントである。
「ｕｂｙｔｅ」は、非暗号化透かし模様データのバイトである。
「ｅｂｙｔｅ」は、暗号化透かし模様データのバイトである。
「ｒ」は、暗号化アルゴリズムにより発生する乱数であり、バイトごとに異なる。
「ｚｅｒｏ＿ｃｏｕｎｔ＋＋」は、増し分ｚｅｒｏ＿ｃｏｕｎｔの増分（increment）を意味する。
「ｉｄｘ＋＋」は、ｉｄｘの増分を意味する。

概略的には、ＭＰＥＧスタートコードが決して間違って生成されないように、暗号化処理は監視される。ＭＰＥＧスタートコードは、例えば３つの１６進法バイト００ ００ ０１である。このようなコードは、非暗号化透かし模様データには発生しないが、暗号化データ中には偶然発生することが起こりうる。このようなコードが暗号化データで発生した場合には、非暗号化データが代わりに使われる。

図１５の処理では、ゼロの列（ステップＳ５７）又はゼロの列の後に１が続く（ステップＳ５８）ものをチェックし、該当する状態が検出された場合には、非暗号化データバイトを出力し（ステップＳ６０）、そうでない場合には、暗号化データバイトを出力する（ステップＳ５９）。

図１５において、暗号化処理（又は復号処理）はステップＳ５０で開始され、ステップＳ５１に進み、「ｉｄｘ」及び「ｚｅｒｏ＿ｃｏｕｎｔ」はゼロに設定される。ステップＳ５２において、「ｉｄｘ」は、暗号化する（又は復号する）透かし模様データのバイト数「ｎｕｍ＿ｂｙｔｅｓ」と比較される。全てのバイトが処理されると、処理は、ステップＳ５３で終了するか、又はステップＳ５４に進み、処理する（次の）透かし模様データバイト「ｕｂｙｔｅ」を取得し、更にステップＳ５５でその透かし模様データを暗号化するための乱数ｒを取得する。ステップＳ５６において、そのデータバイトは、ｅｂｙｔｅ＝ｕｂｙｔｅＸＯＲｒの演算により暗号化される。ステップＳ５７、Ｓ５８において、得られたデータストリーム中にＭＰＥＧスタートコードがありそうかどうかをチェックする。ステップＳ５７において、ｕｂｙｔｅ又はｅｂｙｔｅがゼロ列かどうかをチェックし、そうである場合には、ステップＳ６０でｕｂｙｔｅを出力する。ステップＳ５８において、ゼロ列があり（ｚｅｒｏ＿ｃｏｕｎｔ＞１）、その後に１が続くかどうか（ｅｂｙｅ＝＝１）をチェックする。ＹＥＳの場合、ｕｂｙｔｅが出力され（ステップＳ６０）、そうでない場合、ｅｂｙｔｅが出力される（ステップＳ５９）。ステップＳ６１で、ｕｂｙｔｅがゼロである場合、ｚｅｒｏ＿ｃｏｕｎｔが増分され、そうでない場合、ｚｅｒｏ＿ｃｏｕｎｔは、ステップＳ６２でゼロに設定され、最後にステップＳ６４で、ｉｄｘは増分されて、処理はステップＳ５２に戻る。

差分ＤＣの再符号化
イントラブロックのＤＣ係数は、スライス全体を通して差分的に符号化される。上述のように、原差分値は格納され、代わりに新たな差分値が計算され、使われる。これにより、所望の、例えば一定の輝度レベルを提供するような変更が可能になり、テンプレートデザインの良好な定義が可能になる。

図４において、Ｉフレームが変更されるものとし、中央のマクロブロック１０が透かし模様データを含むことになるテンプレート内のマクロブロックであり、その左右のマクロブロックは、テンプレートの外側にあるものと仮定する。左側のブロックのＤＣ差分６０は、テンプレートの外側にあり、透かし模様の影響を受けない。ＤＣ差分６１〜６４は、テンプレート内にある。ＤＣ差分６１〜６４は、そのマクロブロックから取り出されて、格納される。ＤＣ差分６１〜６４は、透かし模様を表す新たな差分値により置換される。説明を簡単にするために、透かし模様が白色レベルの領域と仮定する。ＤＣ差分６１は、所望の白色レベルを表す新たな差分値で置換され、ＤＣ差分６２〜６４は全て、ＤＣ差分６１と同じ白色レベルを表すからゼロに設定される。ＤＣ差分６５は、再計算される。テンプレート外に出るときには、その原差分値（すなわち、ブロック６５の）を新たな値で置換する動作が伴う。洗浄中には、逆の処理ができるので、（ブロック６５の）原差分値を格納する必要はない。それは、以下の（ａ）と（ｂ）との差から計算できるからである。（ａ）非差分値に変換された透かし模様埋込み差分値から計算されたブロック６５の値、（ｂ）ブロック６４の原（洗浄された）非差分値。

図４では、テンプレートはマクロブロックと一致すると仮定する。これは、入口点と出口点の数を最小にし、ゼロＤＣ差分の数を最大にするので有利である。しかしながら、テンプレートは、マクロブロックと一致しなくともよい。

Ｐ及びＢフレーム
Ｐ及びＢフレーム内のイントラ符号化マクロブロックは、上述と同じように変更できる。非イントラ符号化マクロブロックは、上述のようにＡＣ ＶＬＣを取り除くことができるが、非イントラ符号化マクロブロックは、予測符号化されているので、その変化は視認できない。動きベクトル透かし模様法は、Ｐフレーム及びＢフレーム上だけで実行できる。

色差（chrominance）
上述の説明では、透かし模様データを輝度情報だけに与えると仮定しているが、マクロブロックは、色差情報のＤＣＴブロックも含んでもよい。上述の輝度に対する方法と同じ方法で、透かし模様データを色差ＤＣＴブロックに含ませてもよい。また、透かし模様データを色差ＤＣＴブロックだけに含ませ、輝度ＤＣＴブロックには含ませなくともよいが、ここではその方法はとられていない。

原画像データ復元の概要（図１６）
図１３（ｃ）において、透かし模様が埋め込まれたビットストリーム（一時画像バッファ７４中の）の一例が示されるが、これは、主バッファ７０に転送されて、デコーダに送信される原ビットストリームを置換する。デコーダで受信されると、原画像が復元されていない場合には、透かし模様が埋め込まれた画像が表示される。図１６は、本発明による原画像の復元（洗浄）処理の例の概要を示している。

ステップＳ２０において、透かし模様が埋め込まれたビットストリームが格納され、構文解析（parse）が行われる。ステップＳ２２において、暗号化透かし模様ユーザデータが、ビットストリームから抽出されて格納される。また、ビットストリームの最後に付加された全てのデータも格納される。ステップＳ２４において、格納された暗号化透かし模様ユーザデータが復号されて、原ＤＣ差分及びＡＣ ＶＬＣが復元される。ステップＳ２６において、復元された原ＤＣ及びＡＣ ＶＬＣで、透かし模様を表すＤＣ差分を置換する。その結果のビットストリームは、透かし模様データを除いたＭＰＥＧ２圧縮ビットストリームとなる。ステップＳ２８において、復元されたビットストリームは、従来のＭＰＥＧ２方法により伸長される。

全ての原係数は、ユーザデータとして保持され、及び／又は、そのビットストリームの最後に付加されているので、原ビットストリームは、完全に復元可能である。結果として得られる洗浄されたファイルは、透かし模様のない原ファイルとビット毎に一致する。

原画像データの復元処理の一例は、後述する「透かし模様洗浄コード」の項目においてより詳細に説明する。

実施の概要（図１７、１８及び１９）
図１７には、透かし模様埋込みシステムの模式図が示されている。ソースからの圧縮されていないデジタルビデオシーケンス５０が従来のＭＰＥＧ２エンコーダ５２に供給される。このようなエンコーダは周知のものである。この実施の形態において、エンコーダ５２は、コンピュータで実行される圧縮ソフトウェアであるが、エンコーダ５２は、専用プロセッサで構成されていてもよい。圧縮ビデオシーケンスは、ファイルとして記憶装置５４、例えばエンコーダ（コンピュータともいう）５２のハードディスクに格納される。

透かし模様埋込み装置５６は、記憶装置５４から圧縮ビデオシーケンスが供給される。この実施の形態の埋込み装置５６は、コンピュータで実行される埋込みソフトウェアであるが、以下に説明するように、埋込み装置５６は、専用プロセッサで構成されていてもよい。埋込み処理には、図９に示すようなテンプレートと、少なくとも１つの暗号化鍵を使用する暗号化アルゴリズムとが携わり、これらの両者は、デコーダで原画像を復元する際に必要になる。この実施の形態においては、埋込装置（コンピュータともいう）５６は、スマートカードインタフェース５７を備え、スマートカードインタフェース５７を介して、テンプレート及び暗号化鍵がスマートカード６４又は他の安全なデータ記録媒体上に安全に格納される。又は、テンプレート及び鍵を、ネットワーク上で安全な方法で又は他の安全な方法で送ってもよい。

埋込み装置５６は、圧縮ビットストリームに対して透かし模様を加える。そして、透かし模様が埋め込まれたビットストリームは、別のファイル記憶装置６０（例えばスタジオ６２内の）に伝送リンク５８を介して伝送され、伝送リンク５８は、無線リンク、ネットワーク、例えばディスク、テープ、他のデータ記憶装置であってもよい。

図１８にデコーダの一例を示す。透かし模様が埋め込まれたビットストリームは、ファイル記憶装置６０から取り出されて、洗浄装置６６とも呼ばれる埋込み解除装置に供給され、原ビットストリームが復元される。この実施の形態における洗浄装置６６は、コンピュータで実行される埋込み解除ソフトウェアであり、これについては後述するが、洗浄装置６６は、専用プロセッサで構成されていてもよい。洗浄処理には、図９に示すようなテンプレートと、少なくとも１つの暗号化鍵を使用する暗号化アルゴリズムとが関わり、これらの両者は、洗浄装置６６で原画像を復元する際に必要とされる。この実施の形態において、洗浄装置（コンピュータともいう）６６は、スマートカードインタフェース６３を備え、スマートカードインタフェース６３を介して、スマートカード６４からテンプレート及び暗号化鍵を受け取る。洗浄装置６６の出力は、圧縮ビットストリームであり、従来のＭＰＥＧ２デコーダ６５に供給され、伸長されて、表示装置６７に表示される。

バッファ
図１９（及び図１７）に示すように、圧縮ビットストリームに透かし模様データを埋め込むために、１つのファイル（図１７の５４）と３つのバッファとが使用される。これらのバッファは、エンコーダ５２からのＭＰＥＧ２規格に準拠した圧縮原ビットストリームを格納して、透かし模様が埋め込まれたビットストリームを出力する主バッファ７０と、原ＤＣ差分及びＡＣ ＶＬＣを格納する透かし模様データバッファ７２と、透かし模様が埋め込まれたビットストリームを、主バッファ７０に伝送するように構成された一時画像バッファ７４とである。これらのバッファは、物理的なバッファでもよいが、この実施の形態ではソフトウエアで定義される仮想バッファである。

洗浄処理では、同様に、主バッファ７０と、透かし模様データバッファ７２と、一時画像バッファ７４との３つのバッファを使用する。

透かし模様の埋込み
次に、上述した様々な処理について、例えば擬似コードを導入する実施の形態について説明する。

透かし模様埋込み−擬似コードの実施の形態
主バッファ及び透かし模様データバッファを生成する
（ＷＨＩＬＥ）画像処理中に
ファイルから１画像分のデータを主バッファに読み込む
一時画像バッファを生成する
（ＷＨＩＬＥ ＮＯＴ）表示画像データの開始前に
主バッファの構文解析をする
全ての選択された透かし模様手法を使用可能にする（透かし模様データバッファにフラグ設定）
（ＷＨＩＬＥ ＮＯＴ）画像終了前に
（ＣＡＬＬ）スライス処理を呼び出す
空間的制約条件が満たされているかを調べる
（ＩＦ）空間的制約条件が満たされていない場合
この画像に対する透かし模様手法の幾つかを使用禁止にする（透かし模様データバッファ内にフラグ設定）
（ＷＨＩＬＥ ＮＯＴ）画像終了前に
（ＣＡＬＬ）スライス処理を呼び出す
画像内に、新たな透かし模様が埋め込まれる表示画像データに利用できるスペースが画像内にあるかを判定する
（ＩＦ）５バイト未満である場合、
（ＩＦ）原ユーザデータが存在する場合
ユーザデータの最後のブロックにフラグを立てて、それが透かし模様でないことを示す
表示画像データを主バッファに出力する
サイズに合わせて画像をゼロバイトを使って埋める
（ＥＬＳＥ）さもなければ
ユーザデータスタートコードを出力する
（ＷＨＩＬＥ）透かし模様データが存在し、（ＡＮＤ）且つ画像内に埋め込むスペースがある場合、
透かし模様データを暗号化する
暗号化透かし模様データを一時画像バッファ内のユーザデータスペースに出力する
ユーザデータのブロックにフラグを立て、それが透かし模様データであることを示す
表示画像データを主バッファに出力する
（ＩＦ）画像内に埋め込むスペースがある場合、
サイズに合わせて画像をゼロバイトを使って埋める
主バッファからの変更画像をファイルに書き込む
透かし模様データバッファに残っている全てのデータをファイルに書き込む。

スライス処理関数（process slice function）
（ＷＨＩＬＥ）スライス中で
（ＩＦ）データが透かし模様手法に関係していない場合
（ＰＯＰ）主バッファからデータをポップし
（ＰＵＳＨ）データを一時画像バッファにプッシュする
（ＥＬＳＥ）さもなければ
（ＰＯＰ）主バッファからデータをポップし
（ＰＵＳＨ）データを透かし模様データバッファにプッシュする
変更値を計算し
変更値を符号化する
（ＰＵＳＨ）変更値を一時画像バッファにプッシュする
透かし模様が埋め込まれたコード
透かし模様が埋め込まれたコードの説明をする。ＭＰＥＧ２規格に準拠したビットストリームは、ファイル、例えば図１７の記憶装置５４に格納され、バッファ７０、７２、７４が生成され、ファイルから１画像分のデータが主バッファ７０に書き込まれて、構文解析が行われる。次に、透かし模様手法の選択が行われる。透かし模様手法の選択については、図２２を参照して以下により詳細に説明する。先ず最初に、全ての透かし模様手法を使用可能にする。次に、別途より詳細に説明する「スライス処理関数」が実行される。概略すると、そのスライス処理関数では、原ＤＣ差分及びＡＣ ＶＬＣを透かし模様データバッファ７２に格納し、新たな透かし模様ＤＣ差分（すなわち変更値）を計算し、変更値を一時画像バッファ７４に格納するものである。

次に、空間的制約条件（space constraint）が満たされているかのチェックを行う。最初は、透かし模様手法の特定の集合の全てがビットストリームに対して適用されるものと仮定する。空間的制約条件が満足されない場合には、手法の１つ以上が使用禁止にされる。この実施の形態の場合、画像からＡＣ ＶＬＣを取り除くことにより解放されるビットの数が、ＤＣ差分の変更を行うのに必要とされるビットの数よりも多い場合、空間的制約条件の１つに合格したことになる。それは、透かし模様を埋め込んだ表示画像が原表示画像より大きくないということを示している。条件が満たされない場合、それは、ＡＣ ＶＬＣの取出しによってＤＣ差分の透かし模様埋込みに対する十分なスペースが解放されなかったことを示す。

選択された手法によってスライス処理関数が再度実行される。この実施の形態における「利用できるスペースを判定する」のステップでは、画像内に、新たなＤＣ差分に利用できるスペースがあるかがチェックされる。

空きスペースが５バイト未満の場合には、透かし模様ユーザデータフィールド２０を含めることはできない。ビットストリームが１つ以上のユーザデータフィールド３６を含む場合は、最後のフィールド３６の最終ビットは、図１２（ｃ）の４０で示すように、ゼロに設定される。透かし模様を表す新たなＤＣ差分を含む表示画像データは、一時画像バッファ７４から主バッファ７０に出力され、画像サイズが、ゼロビットによりその原サイズに合わせてパディング（padded）される（図１１、１２の２２を参照）。

例えば、透かし模様を表す新たなＤＣ差分を含むピクチャデータ内に十分なスペースがある場合には、ユーザデータスタートコードを出力することにより、透かし模様ユーザデータフィールド２０が一時画像バッファ７４内に生成される。透かし模様データバッファ７２内に格納されていた原ＡＣ ＶＬＣ及びＤＣ差分は、暗号化されて、一時画像バッファ７４内の透かし模様ユーザデータフィールドに置かれる。図１２（ｂ）の３８で示すように、透かし模様ユーザデータフィールドの最後のビットは「１」に設定され、それが原ＡＣ ＶＬＣ及びＤＣ差分を含んでいることを示す。一時画像バッファ７４の内容は、主バッファ７０に出力される。透かし模様が埋め込まれた表示画像データスペース２３を挿入するスペースがある場合、表示画像データスペーススペース２３は、図１１の２２で示すように、ゼロビットで満たされる。次に、主バッファ７０のデータは、ファイルに書き込まれる。透かし模様データバッファ７２に残っているデータ、すなわち原ＡＣ ＶＬＣ及びＤＣ差分データで透かし模様ユーザデータ内に置かれないデータは、暗号化され、ファイルを構成するビットストリームの最後に同様に付加される。

スライス処理関数
この処理の説明に際して、この実施の形態においては、図５において説明したように、データは、スライスで処理される。しかしながら、それは必須条件ではない。それは、単にソフトウェアを実行させる際に便利だからである。

コード「ＰＯＰ」は、データがバッファから取り出されることを示す。コード「ＰＵＳＨ」は、データがバッファに移動されることを示す。

かくして、上述したように、主バッファ７０のデータは構文解析される。主バッファ７０内では、表示画像データの「開始」までの全てのデータはスキップされて、そこに残される。一時画像バッファ７４にプッシュ（ＰＵＳＨｅｄ）されるデータだけが、表示画像データである。これにより、原ユーザデータブロックを変更することが容易になる。透かし模様ユーザデータを追加しなければならない場合には、これを透かし模様埋込み表示画像データの前に挿入することが必要である。透かし模様データに関連するデータ、例えばＡＣ ＶＬＣ及びＤＣ差分は、主バッファ７０から取り出されて、透かし模様データバッファ７２に置かれる。ＤＣ差分の新たな変更値が計算され、符号化されて、一時画像バッファ７４に置かれる。

透かし模様の洗浄−擬似コードの実施の形態
主バッファ及び透かし模様データバッファを生成する
（ＣＡＬＬ）透かし模様データ初期化設定を呼び出す
（ＷＨＩＬＥ）画像処理中に
１画像分のデータをファイルから主バッファに読み込む
一時画像バッファを生成する
（ＣＡＬＬ）透かし模様データ取得を呼び出す
（ＷＨＩＬＥ ＮＯＴ）表示画像データの開始前に
主バッファの構文解析をする
透かし模様データ内のフラグ設定により示される透かし模様手法を使用可能にする
（ＷＨＩＬＥ ＮＯＴ）画像終了前に
（ＣＡＬＬ）スライス処理を呼び出す
一時画像バッファの内容を主バッファに出力する
（ＩＦ）画像内に埋め込むスペースがある場合
ゼロで埋める
主バッファからの変更画像をファイルに書き込む。

透かし模様データ初期化関数
透かし模様ユーザデータブロックをファイルから分離する
データを復号する
一時ファイルに格納する。

透かし模様データ取得関数
（ＩＦ）透かし模様データバッファが満杯でなく、（ＡＮＤ）且つ透かし模様データがまだ一時ファイルにある場合
透かし模様データを一時ファイルから透かし模様データバッファに読み込む
スライス処理関数（透かし模様埋込みに使用した関数とは同一ではない）
（ＷＨＩＬＥ）スライス内で
（ＩＦ）データが透かし模様手法に関係していない場合
（ＰＯＰ）主バッファからデータをポップし
（ＰＵＳＨ）データを一時画像バッファにプッシュする
（ＥＬＳＥ）さもなければ
（ＰＯＰ）主バッファからデータをポップし
（ＰＯＰ）透かし模様データバッファから原データをポップし
（ＰＵＳＨ）元の値を一時画像バッファにプッシュする。

透かし模様洗浄コード
透かし模様洗浄コードは、原画像データを復元する。例えば、洗浄装置６６には主バッファ７０と、透かし模様データバッファ７２と、一時画像バッファ７４とが生成される。更に、「透かし模様データ初期化関数」により一時ファイルも生成される。

この透かし模様データ初期化関数は、ファイルから透かし模様ユーザデータブロック、すなわち暗号化された原ＡＣ及びＤＣ差分を分離し、それらを（スマートカード６４の暗号化鍵を使って）復号し、復号されたＡＣ ＶＬＣ及びＤＣ差分を一時ファイルに格納する。

洗浄されていないピクチャデータが存在する場合、そのデータは一時ファイルから主バッファ７０に読み込まれる。この段階で一時画像バッファ７４が生成される。

「透かし模様データを取得する」関数は、透かし模様データバッファ７２が満杯でなく、（ＡＮＤ）且つ透かし模様データがまだ一時ファイルに存在しているかどうかを判定する。存在している場合、透かし模様データが一時ファイルから透かし模様データバッファ７２に読み込まれる。これにより、透かし模様データバッファ７２内には、常に少なくとも現在の画像を洗浄できる十分なデータが存在することが保証される。

「・・・、透かし模様手法を使用可能にする」のステップでは、透かし模様データから１ビットのフラグを読み出し、選択された全ての手法を用いて画像への透かし模様の埋込みが成功したかどうかを判定する。そうでない場合、次に、追加フラグビットを読み出してどの手法が用いられたかを判定する。

「スライス処理呼出し」のステップは、以下のように動作する。

ＰＯＰ（取出し）及びＰＵＳＨ（移動）は、上述と同じ動作を示す。主バッファ７０のデータは、構文解析される。主バッファ７０内のデータで透かし模様に関係ないものは、取り出されて、一時画像バッファ７４に置かれる。透かし模様データ（すなわち、透かし模様を表すＤＣ差分）は、主バッファ７０から取り出される。透かし模様データバッファ７２内の復号された原ＡＣ ＶＬＣ及びＤＣ差分は取り出されて、一時画像バッファ７４に置かれる。

更なるステップにおいて、そのデータを一時画像バッファ７４から主バッファ７０に転送する。

最後に、再生された画像が主バッファ７０からファイルに書き込まれる。

なお、上述の処理では、どのブロックに透かし模様が含まれ、どのブロックには含まれていないかを判定するために、データ記録媒体６４に格納されたテンプレートが必要である。更に、復号に必要な鍵もデータ記録媒体６４から受け取る。

後述する「第４の実施の形態−動きベクトル」の項目で変更された動きベクトルも同様な方法で元の値に復元される。

第２の実施の形態
非イントラＤＣの変更（non-intra changes）
上記第１の実施の形態においては、Ｉフレーム（Intra-frames）のテンプレートブロック内のＤＣ係数の原ＤＣ差分を透かし模様を表す新たな値で置換することにより、透かし模様が加えられる。それ以外の係数は置換されない。元の値は、透かし模様ユーザデータスペース及び／又はビットストリームの最後に格納される。

本発明の第２の実施の形態においては、ＩフレームのＤＣ係数の置換に加えて、非Ｉフレーム（すなわちＰフレーム及びＢフレーム）のテンプレートブロック内のＤＣ係数が新たな値で置換され、元の値が、透かし模様ユーザデータスペース及び／又はそのビットストリームの最後に格納される。

非Ｉフレームにおいて、ＤＣ係数の変化の程度は通常小さいので、ＤＣ係数を、現在の係数と所望の係数との差として符号化する。しかしながら、その変化の程度がかなり大きい場合もあり、透かし模様ブロックのＤＣ値が制限範囲でクリップ（clip）してしまう場合がある。これを避けるために、ＤＣ係数の大きさを最小値「１」に変更することができる（その値をゼロに変更すると、ＡＣ_ＶＬＣは完全になくなり、後に続くコードのランレングス（run-length）が変わる）。

原ＶＬＣは、透かし模様データバッファ７２に格納されて、新たなコードがその位置に置かれる。ランレングスがゼロ及びレベル変化が１を表すＶＬＣは、符号化テーブル内で最小のＶＬＣであり、この処理により、画像を符号化するのに必要なビット数が決して増加しないことが保証される。したがって、それは、イントラＤＣ変更（intra DC changes）が行われる場合に合わせて、何時でも実行することができる。

レベル変化の符号は、ＤＣ変更が黒色に対してはプラスに設定され、その変更が白色に対してはマイナスに設定される。これにより、ＤＣクリッピングの発生が防げる。

図２０において、非Ｉフレームは以下のように処理される。ステップＳ３０において、フレームタイプを判定する。フレームが非Ｉフレームである場合、処理はステップＳ３２に進む。一方、フレームがＩフレームである場合、処理は、図１０で述べたように進む。ステップＳ３４において、テンプレートブロック内のＤＣ係数（これは上述した差分値）を表すコードは、取り出されて、透かし模様データバッファ７２（図１２（ｂ）参照）に格納される。ステップＳ３６において、新たな変更値＋／−１が、取り出されたＤＣ係数の代わりに、ビットストリームに配置される。ステップＳ３６及びＳ３８において、ビットストリームは、一時画像バッファ７４内で再構成される（図１２（ｃ）を参照）。利用できるスペースがある場合、取り出された係数値を、透かし模様ユーザデータスペース２０に置き、スペースがない場合は、ステップＳ４０において、ビットストリームの最後に付加する。原ＤＣ係数は、上述のように暗号化される。

ＡＣ ＶＬＣは、非Ｉフレームにおいては変更されない。

第３の実施の形態：フレームピクチャ、ＤＣＴタイプの変更、図２１
第１及び第２の実施の形態は、以下のように変更してもよい。

ピクチャのタイプには、フィールドタイプとフレームタイプの２つのタイプがある。フィールドピクチャにおいては、ＤＣＴブロックの１タイプだけが発生する。

第３の実施の形態においては、フレームピクチャだけについて検討する。フレームピクチャにおいては、フィールドとフレームの２つのタイプのＤＣＴブロックが生じうる。フィールドＤＣＴは、ビデオソースがインタレースされている場合に使用され、それは、隣接する行間の相関を改善でき、その結果、ＤＣＴの低周波数成分の信号出力の割合が改善できるからである。しかしながら、それは、この目的のためだけに使用されるのではない。マクロブロックにおいては、全てのブロックは同じタイプを有する。

図２１（ａ）において、同じマクロブロックＭＢ内の垂直方向に直接上下のＤＣＴブロックではなく、１つのＤＣＴブロックＢ１に対してフレームピクチャ内のＤＣ変更がなされ、そのマクロブロックのＤＣＴブロックにフィールドタイプが用いられる場合、変更の結果、マクロブロックの高さに全体亘ってストライプ（stripes）が発生する。これは、透かし模様を歪ませ、透かし模様が英数字（alpha-numeric）の場合には、読みづらくなるので好ましくない。

ストライプの現れ方は、コンテンツの符号化と、特にフィールドＤＣＴを使って符号化されたマクロブロックの割合とに完全に依存する。本発明の実施の形態によれば、この問題を解決するために、少なくとも１つの透かし模様が埋め込まれるＤＣＴブロックを含む、フレームピクチャ内のいずれのＤＣＴタイプのマクロブロックも、フレームに設定される。これは原ＤＣＴタイプコードを透かし模様データバッファ７２（図１３）に格納して、それをフレームＤＣＴ用コードで置換する動作を伴う。ＤＣＴタイプコードは常に１ビット値であるから、そのピクチャが要求するビット数に影響を及ぼさない。したがって、この変更は、ＤＣ透かし模様を使用する際には何時でも行える。

動きベクトルの変更と同様に、ＤＣＴタイプはマクロブロックレベルで機能するので、どの変更でも、透かし模様埋込みの有無に拘わらず、マクロブロック内の全てのＤＣＴブロックに影響を及ぼす。この場合、発生する副作用は、マクロブロック内の行の再配列が生ずることである。この結果、明瞭、視認可能で不正なマクロブロックが生ずる場合があるが、マクロブロックの現れ方は必ずしも受け入れ難いとは言えないかもしれない。

図２１（ｂ）は、ＤＣＴタイプを処理する方法の一例を説明する（フィールドＤＣＴからフレームＤＣＴへの変更及びその逆の変更を含む）。

図２１（ｂ）において、
「ｐｉｃｔｕｒｅ＿ｓｔｒｕｃｔｕｒｅ＝＝ＦＲＡＭＥ」は、フレームピクチャを検出する。
「＆＆」は論理積。
「ｆｒａｍｅ＿ｐｒｅｄ＿ｆｒａｍｅ＿ｄｃｔ＝＝０」は、マクロブロックがこのピクチャに対して普遍的に設定されるフレームＤＣＴタイプではなく、個々のベースに基づき特に設定されたＤＣＴタイプを有することを検出する。
「｜｜」は論理和である。
「ｍａｃｒｏｂｌｏｃｋ＿ｉｎｔｒａ｜｜ｍａｃｒｏｂｌｏｃｋ＿ｐａｔｔｅｒｎ」は、イントラ符号化マクロブロック（intra-encoded macroblocks）及び符号化ＤＣＴブロックを含む非イントラブロック（non-intra blocks）を検出する。イントラ符号化マクロブロックは、符号化された全てのＤＣＴブロックを有する。符号化ブロックだけがＤＣＴタイプを有するので、この検出が必要である。

ＤＣＴタイプ（ｄｃｔ＿ｔｙｐｅ）は、１ビットのコードで表される。１＝フィールドタイプであり、０＝フレームタイプである。

原ビットストリームは、主バッファ７０に格納されており、取り出されたコードは、透かし模様データバッファ７２に一時的に格納される（図１３参照）。

処理は、ステップＳ７０から始まり、ステップＳ７１更にステップＳ７２に進み、ＤＣＴタイプを有するマクロブロックが検出される。マクロブロックがＤＣＴタイプを持たない場合、処理は、ステップＥＮＤで終了する。マクロブロックがＤＣＴタイプを有する場合には、ステップＳ７３において、ＤＣＴタイプを表す１ビットのコードが主バッファ７０から取り出される（ポップされる）。ステップＳ７４において、ＤＣ変更が可能にされ（以下に述べる「選択手法」の項目を参照）、マクロブロックがテンプレート内にあることが判定される。ＹＥＳの場合、ステップＳ７５において、透かし模様をビットストリームに埋め込むのか、又は、透かし模様が埋め込まれたビットストリームをその元の形に復元（洗浄）するのかが判定される。ビットストリームに透かし模様を埋め込む場合には、次のステップＳ７６において、「ｄｅｔ＿ｔｙｐｅ」コード（ステップＳ７３において主バッファ７０から取り出されたもの）が透かし模様データバッファ７２（図１３参照）に置かれる（プッシュされる）。そして、ステップＳ７７において、「ｄｅｔ＿ｔｙｐｅ」コードの値は、フレームタイプ（＝０）に変更され、ステップＳ７９において、その新たなコードが一時画像バッファ７４にプッシュされる（図１３を参照）。

ステップＳ７４からＮＯの経路が取られると、ポップされた「ｄｅｔ＿ｔｙｐｅ」コードは、ステップＳ７９において、一時画像バッファ７４にプッシュされる。

その逆の処理においても、ステップＳ７０〜Ｓ７４までは、上述のように進む。次に、ステップＳ７５において、透かし模様埋込み処理が反転（洗浄）されようとしているかが判定されて、ステップＳ７８において、透かし模様が埋め込まれたストリームの「ｄｃｔ＿ｔｙｐｅ」コードが、透かし模様データバッファ７２から抽出された原コードによって置換される。次にステップＳ７９において、その「ｄｃｔ＿ｔｙｐｅ」コードは、上述と同じように、一時画像バッファ７４に格納される。

図２１（ｂ）に示す処理の最後において、一時画像バッファ７４は、新たな「ｄｃｔ＿ｔｙｐｅ」コードを含み、透かし模様データバッファ７２は、原コードを含む。透かし模様データバッファ７２からの原コードは、透かし模様ユーザデータスペース２０に転送されるか、又はそのビットストリームの最後に付加される。新たな「ｄｃｔ＿ｔｙｐｅ」コードが、原コードの代わりに、ビットストリームに置かれる。それらは、上述した「透かし模様が埋め込まれたコード」の項目で説明したのと同様に行われる。

選択手法
上述したように、ピクチャには、下記のステップにより、透かし模様が埋め込まれる。
（ａ）第１の実施の形態：原ＤＣ及びＡＣ係数を表す全てのコードをＩフレームのテンプレートブロックから取り外し、そのＤＣ係数を、透かし模様を表す新たな値で置換する。
（ｂ）第２の実施の形態：オプションとして更に加えて、非Ｉフレーム内の原ＤＣ係数を表すコードを取り外し、それらを新たな値で置換する。
（ｃ）オプションとして、上述に更に加えて、テンプレートブロックの原動きベクトル値をゼロ値で置換する。

より一般的には、次の３つの手法が用いられる。
１．テンプレートブロック内のＤＣ係数の変更を許可する。
２．テンプレートブロックからＡＣ係数の取外しを許可する。
３．テンプレートブロック内の動きベクトルの変更を許可する。

通常、ここで説明する実施の形態の手法を用いて透かし模様を埋め込んだ画像を符号化するために必要なビット数は、原画像より少なくて済む。上述の第１の実施の形態においては、これは、ＡＣ係数を完全に除外することによるが、ＤＣ及び動きベクトル両方に対して多数のゼロ差分値で符号化した効果も大きい。

しかしながら、透かし模様を完全に埋め込もうとしても、ピクチャの最後に挿入するビットの数がその画像から取り外したビット数よりも大きくなってしまう場合がある。例えば、これは、ビデオシーケンスで通常遭遇する完全に黒いカラーフレーム等で容易に生じうる。これが発生する場合、画像を表すのに使用するビット数は同じに維持されなければならないという制約条件を満たすために、その条件が満たされるまで画像の透かし模様の埋込みに使用する上述した手法の幾つかを使用禁止にする必要がある。

本発明の実施の形態においては、その選択は、各ピクチャベースで行われるので、その画像の正しい洗浄を容易にするためには追加情報を格納する必要がある。そこで現在の画像に対してどの手法が許可されているかを示すフラグビットが挿入される。ここで使用される方式が表Ａに示される。それは、更なる手法の追加にも容易に適応し、且つ利用できる全手法の集合の中から選択された部分集合であるにも拘わらず効率的である。ここで注目する点は、第１のフラグビットの選択が透かし模様が埋め込まれたデータ内でのＭＰＥＧ２スタートコードの発生を避けるように設計されていることである。

可能な限り常にイントラＤＣ変更とＡＣ取外し手法の２つは、最低限適用されるべきである。これにより、良好な視認性と頑強性が与えられるからである。イントラＤＣ変更が加えられる場合には、非イントラＤＣ及びＤＣＴタイプ変更も用いることができる。その画像が必要とするビット数が増加しないことが保証されているからである。動きベクトルの変更も視認性品質や透かし模様の完全性を改善するが必須条件ではない。

図２２は、例えば３つの透かし模様埋込み手法の選択を説明するフローチャートである。
１．テンプレートブロックにおけるＤＣ係数の変更を許可する。
２．テンプレートブロックからのＡＣ係数の取外しを許可する。
３．テンプレートブロック内の動きベクトルの変更を許可する。

なお、ここで注意すべき点は以下のとおりである。
・解放されたＡＣビットは、常に、負ではない。ＡＣ取外しは、何時でも実行でき、決して画像サイズの増加を起こさない。
・ＤＣ変更用ビット及びＭＶ変更用ビットは、正であっても、負であってもよい。その値が正の場合は、その手法を実行するのに必要なビット数は元々存在したビット数より大きくなる。したがって、現在の画像に対する変更を行う場合は、別の手法を用いて（例えばＡＣ取外し）十分なビット数を解放しなければならない。その値が負の場合は、その手法は元々存在したビット数よりも少ないビット数しか必要とせず、したがって、実際には十分なビットが解放されているので、その変更は何時でも実行することができる。

解放されたビット数が両者の手法を実行するのに必要とするビット数を補うのに不十分な場合には、ＭＶ変更よりもＤＣ変更が常に優先される。

図２２において、処理は、ステップＳ８０から始まり、ステップＳ８１に進み、ここで、最初は３つの手法全てが使用可能される。ステップＳ８２において、画像（すなわちフレーム又はフィールド）は、使用可能にされた３つの手法の全てを適用するよう処理される。ステップＳ８３は、再処理フラグを「True」に設定して、最初は３つの手法の全てを用いてその画像が再処理できると想定していることを示す。概説すると、画像は、１つのパス（pass）においては３つの手法の全てを用いて透かし模様を適用するように処理されて、結果が解析される。その結果が不首尾の場合は、その画像は、１つ以上の手法を使用禁止にした第２のパスにて再処理される。

３つの手法の全てを可能にする解放されたＡＣビット
ステップＳ８４において、ＡＣ係数を取り除くことにより、データが削除され、ＤＣ係数変更のためのビット解放がなされたかどうかを判定する（黒色画像に対してはＡＣ係数はないかもしれない）。解放されたビット数がゼロを超えれば、次にステップＳ８５において、解放されたＡＣビット数が、ＤＣ変更用ビットとＭＶ（動きベクトル）変更用ビットの和以上かどうかを判定する。ＤＣ変更用ビット数は、原ＤＣコードを取り除くことにより解放されたビット数と新たなＤＣコードに使用されたビット数との差である。同様に、ＭＶ変更用のビット数は、原ＭＶコードを取り除くことにより解放されたビット数と新たなＭＶコードに使用されたビット数との差である。

解放されたＡＣビット数がＤＣ変更用及びＭＶ変更用ビットの合計より少なくない場合には（すなわち、ＤＣ及びＭＶ変更の両方ができるだけの十分なＡＣビットが解放された場合）、３つの手法の全部が使用でき、したがって、画像の再処理の必要はなくなる。かくして、その再処理フラグは、ステップＳ９０において、「False」に変更される。ステップＳ９１は、再処理フラグが「True」、「False」いずれかを判定する。この場合は、「False」であるので、処理はステップＥＮＤで終了する。

ステップＳ８４：解放されたＡＣビットがない場合
これは、ＡＣ係数を持たず、したがって透かし模様を埋め込むことができない黒色画像上で起こることがある。黒色画像には保護するコンテンツがないので、それは問題にはならない。

ステップＳ８４において、解放されたＡＣビットがないこと確認されると、処理はステップＳ９３に進み、そこにおいて、ＡＣ取外し手法が使用禁止になる。ステップＳ９４は、ＤＣ変更用のビットがゼロより大きいかをテストする。大きい場合、ＤＣ変更手法は、ステップＳ９５において、使用禁止にされる。ＤＣ変更用のビットがない場合、すなわちステップＳ９５が起こった場合には、処理はステップＳ９６に進み、そこにおいて、ＭＶ変更用のビット数がゼロより大きいかどうかがテストされる。大きい場合、ステップＳ９７において、ＭＶ変更手法が使用禁止にされる。

要約すると、ＡＣビットが解放されない場合、ＤＣ及びＭＶ変更は許可されず、又はＤＣ及びＭＶ変更ビットがないということである。何れの場合でも再処理フラグは依然「True」であるので、画像は、ステップＳ９２において、（再度）処理される。

なお、「解放されたＡＣビット」は、常に負でなく、一方、「ＤＣ変更用ビット」及び「ＭＶ変更用ビット」は、正であっても、負であってもよい。取り除くＡＣデータがない場合、ＤＣ及びＭＶの変更は、その置換データが原データよりもビット数が少ない（すなわち、「ＤＣ変更用ビット＜＝０」且つ「ＭＶ変更用ビット＜＝０」）場合にだけ実行できる。したがって、ＡＣ取外しを使用禁止にする一方で、ＤＣ及び／又はＭＶ変更を許可することも（可能性は低いが、）可能である。

３つの手法の全部を許可すると最初に仮定しているので、手法のどれかを使用禁止にした場合には、常に再処理が必要になり、フラグデータを変更しなければならず、第１のパスで透かし模様が埋め込まれたフレームは、第２のパスの透かし模様が埋め込まれたフレームで上書きされる。

ＡＣ ＶＬＣデータの不足は、ビット数を増加させる差分ＤＣ値の変更を使用可能にするピクチャデータのスペース解放ができないことを意味する。そのような場合においては、透かし模様の埋込みはできなくとも、保護するコンテンツがないので問題にはならない。しかしながら、ここでは透かし模様洗浄装置と呼ぶ、透かし模様を取り外すデコーダは、フレームから透かし模様を取り除こうとしなくても済むようにどこでそのような場合が発生したかを通知されなければならない。これを示すのに、追加フラグビットが用いられる。

ＡＣビットがＤＣ及びＭＶ変更用ビットの総和より少ない場合：ステップＳ８５
ＤＣ及びＭＶ変更の両方を行うのには解放されたビット数が不足する場合には、処理はステップＳ８６に進む。

この場合、ステップＳ８６は、解放されたＡＣビット数がＤＣ変更を行うのには十分かどうかを調べる。ＤＣ変更を行うのに十分なビットがある場合（ステップＳ８６のＮＯ出力）、ステップＳ９７に進みＭＶ変更は不許可となる。次に処理はステップＳ９１に進む。再処理フラグは「True」であるがＭＶ変更は不許可なので、次に、ステップＳ９２において、画像は、ＭＶ変更不許可且つＤＣ変更許可の状態で改めて処理される。

ステップＳ８６においてＤＣ変更を行うのには解放されたビットが不十分であると判定された場合（ステップＳ８６の出力ＹＥＳの場合）、次に処理はステップＳ８７に進み、そこにおいて、解放されたＡＣビット数がＭＶ変更を行うのには十分であるかどうかを判定する。ＭＶ変更を行うのには十分なビットがある場合（ステップＳ８７の出力ＮＯ）、次にステップＳ８８において、ＤＣ変更が使用禁止にされる。次に、処理はステップＳ９１に進む。再処理フラグは「True」であるが、ＤＣ変更が不許可になっているので、次に、ステップＳ９２において、画像は、ＤＣ変更不許可且つＭＶ変更許可の状態で改めて処理される。

ステップＳ８７において、そのＭＶ変更を行うのにはビットが不十分であると確認されると（ステップＳ８７の出力ＹＥＳの場合）、次にステップ８９において、ＤＣ及びＭＶ変更の両方が不許可にされて、その画像はＡＣ取外し手法だけが有効にされてステップＳ９１及びＳ９２により再処理される。

図２２の処理の変形例において、ＡＣを取り外しても問題が決して起きないのが分かっているので、ＡＣ取外し機能は、常に有効（使用可能）となっている。図２２においてステップＳ９３は取り除かれＡＣ取外しのためのフラグビットは必要でなくなる。

第４の実施の形態：動きベクトル：図２３−２５
動きベクトルのゼロ設定
図２３（ａ）において、動きベクトルは、ＤＣＴブロック（細線で示された四角形Ｂ）よりもむしろマクロブロック（太線で示された四角形ＭＢ）と関連付けられる。そこで、明るい陰影で示される動きベクトルテンプレートは、暗い陰影で示される透かし模様テンプレートに基づいて定義されてもよい。上述の第１の実施の形態において仮定したように、Ｉフレームだけが透かし模様データを含んでいるとしても、動きベクトルは、透かし模様を歪ませてしまうことがある。Ｐ及び／又はＢフレーム内のどのマクロブロックが動きベクトルテンプレート内にあるかを判定することが、必須ではないが、好ましい。もしあれば、次に、そのマクロブロックの動きベクトルの値がゼロに設定される。動きベクトルは、差分に基づきに符号化されるので、差分値は、動きベクトルに対してゼロの値を表すように設定される（すなわち、動きベクトルは、上述のＤＣ差分に対すると同じように処理される）。

ＤＣ差分を引用して説明したように、ＤＣＴマクロブロックの動きベクトルを表す原コードは、テンプレート内のＤＣＴブロックを含み、ビットストリームから取り出されて、変更コードで、この場合は、ゼロ値の動きベクトルを表すコードで置換される。原動きベクトルコードは、透かし模様ユーザデータスペース２０に置かれ、及び／又はそのビットストリームの最後に付加される。

そこで、図１３及び２４を参照してさらに説明する。

ビットストリームは主バッファ７０に格納されている。

ステップ１００において、非Ｉフレームのマクロブロックが動きベクトルテンプレートに属するかどうかが判定される。そうであれば、そのマクロブロックと関連する動きベクトルコードは、主バッファ７０内でビットストリームから取り外され（ステップＳ１０２）、透かし模様データバッファ７２に格納される（ステップＳ１０４）。動きベクトルに対するゼロ値を表す新たな動きベクトルコードが一時画像バッファ７４内のビットストリーム内の元の値の変わりに置かれ（ステップＳ１０６）、原動きベクトルコードは、一時画像バッファ７４内の透かし模様ユーザデータスペース２０に置かれ（ステップＳ１０８）、及び／又はＭＰＥＧ２規格に準拠したビットストリームの最後に付加される（ステップＳ１１０）。原動きベクトルコードは、透かし模様ユーザデータスペース２０に置かれる前又はビットストリームの最後に付加される前に、図１５で上述したように、暗号化される。

上述した実施の形態の何れにおいても、この項目で説明したように、動きベクトルはゼロに設定してもよい。これにより、透かし模様の歪みは少なくなっても、依然として、透かし模様は、特にエッジ部分において歪が残る場合がある。次の項目「境界領域」において、透かし模様の歪みを更に削減する方法を説明する。

境界領域：図２３（ｂ）
図２３（ｂ）に示すように、透かし模様の歪みを更に少なくするために、動きベクトルテンプレートを、透かし模様テンプレートブロックは含まないが、それと境界を接するマクロブッロクを含むように拡張する。拡張された動きベクトルテンプレート内の全てのマクロブロックの動きベクトルコードを、上述の図２４で説明したように処理する。

これにより、透かし模様テンプレートによって定義される透かし模様の歪みは、小さくなるが、透かし模様テンプレートと境界をなすマクロブロックは、透かし模様ブロックを含まないので、画像は、境界線上のマクロブロックにおいて歪む。透かし模様の歪みの削減より画像の歪み増加の影響が大きいと判断するかどうかは、主観の問題である。

動きベクトルコードの値の変更：図２５
動きベクトルは、「差分ＤＣの再符号化」の項目で説明したのと同様に、差分符号化され、記録される。Ｐフレームは前方予測動きベクトルを有するが、Ｂフレームは、前方予測及び後方予測の２つのタイプの動きベクトルを有する。この２つのタイプは、図２５で述べるように、別々に処理される。

図２５（ａ）は、透かし模様の一部ではない、その境界の他のマクロブロック０の間にある３つのマクロブロックＢからなる非常に単純化された動きベクトルテンプレートを示す。

図２５（ｂ）は、予測型のマクロブロックを示す。Ｆは前方（forward）を示し、Ｂは後方（backward）を示す。幾つかのマクロブロックＦＢは、前方及び後方予測のマクロブロックである。

図２５（ｃ）から（ｅ）において、これら図中の数字は、単に説明のためだけであり動きベクトルの実際の値を表すものではない。図２５（ｃ）は、前方予測動きベクトルの非差分値を示す。対応する差分値（それらの差を取った値）を図２５（ｄ）に示す。後方予測動きベクトルは無視されているのが分かる。３つのテンプレートマクロブロック内の動きベクトルがゼロに設定されると、テンプレート内の有効値は、結果的にゼロであるが、そのプレート外の隣接するブロックの有効値が変更されないように、これらのブロックの差分が再計算される。その結果、その先行のマクロブロックに対して変化する、「入口（Entry）」で矢示されるテンプレートの先端部のマクロブロックの差分値が結果的にゼロの動きベクトル値を与え、且つ「出口（Exit）」で矢示される後続端部のマクロブロックの差分値が境界を接する次のマクロブロックの元の値を保持するように変化する。

前方予測動きベクトル値は後方予測値からは独立した差分値シーケンスであり、２つのシーケンスの「入口」及び「出口」のマクロブロック同士は必ずしも一致しないことが理解できる。

更に、テンプレートからの「出口」と境界を接するマクロブロックの動きベクトルの原差分値は、上述の「差分ＤＣの再符号化」の項目のブロック６５で説明したように、格納する必要はないが、そうすることが望ましいのも理解できよう。

テンプレート：図２６〜２８
以上述べたように、２つのタイプのピクチャ、フィールドタイプとフレームタイプの画像がある。ビデオシーケンスは、フィールドピクチャだけ、フレームピクチャだけ、又はフィールドピクチャ及びフレームピクチャの両方を含んでもよい。

フレームピクチャだけのシーケンス
フレームピクチャだけのシーケンスについて考える。テンプレートは、水平及び垂直方向における１つのＤＣＴブロック単位（８ｘ８画素）の解像度で定義する。図２６（ａ）に示す、行当たり７２０画素及び５７６行を有するフレームピクチャの例に対して、必要なテンプレートサイズは９０ｘ７２ブロックである。図２６（ｂ）においてＸの字の形のテンプレートが１ブロック単位の解像度で定義されている。その結果、図２６（ｃ）に示す透かし模様を埋め込んだ画像は、１ブロック８ｘ８画素の表示された透かし模様解像度を有する。

フィールドピクチャだけのシーケンス
フィールドピクチャだけのシーケンスを考える。図２７（ａ１）及び（ａ２）において、それぞれが７２０ｘ２８８画素の２つのフィールドがインタレースされて７２０ｘ５７６画素の１つのインタレースされたフレームを定義する。フィールドピクチャにおいては、ＤＣＴブロックはフレームピクチャの行数の半分の行数であっても８ｘ８画素ブロックに対応している。マクロブロックは、フレームピクチャにおける場合と同様に、２ｘ２ＤＣＴブロックである。

フィールドピクチャに対するテンプレート（図２７（ｂ）におけるＸ）は、１ＤＣＴブロックの解像度で定義される。ストライプの発生を防止するために、両方のフィールドに対して同じテンプレートが使用される。ブロックの位置はフィールドの開始に対して固定されているので、それぞれのフィールドに対する特別の調整は必要ない。

図２８において、図２８（ｃ）に示される１つのマクロブロックに対して、テンプレートは、１つの黒く塗りつぶしたブロックに透かし模様を埋め込むことを示している。インタリーブされたフレームにおいて、図２８（ａ）及び（ｄ）に示すように、それぞれ２つのフィールドからの２つのマクロブロックがインタリーブされて、水平方向に２つのＤＣＴブロックと垂直方向に４つのＤＣＴブロックを組み合わせた１つの複合マクロブロックが構成される。その複合マクロブロックは、フィールド１からのマクロブロックＢ１とフィールド２からのマクロブロックＢ２からなる。インタレースされたフレームの線分は、フィールド１からの線はＦ１により、フィールド２からの線はＦ２により示される。

表示された透かし模様Ｘの解像度は、図２８（ｃ）に示すように、テンプレートの解像度は８ｘ８画素であっても、図２８（ｄ）に示すように、水平に８画素×垂直に１６画素の解像度を有する。

フィールドピクチャ及びフレームピクチャのシーケンス
少なくとも１つのフィールドピクチャと少なくとも１つのフレームピクチャを有するビデオシーケンスを考える。そのテンプレート、図２７（ｂ）のＸは、１つ以上のフィールドピクチャ用に設計されており、１ＤＣＴブロックの解像度を有する。その結果、水平に１ブロック×垂直に２ブロックの解像度を有する透かし模様が表示される。１つ以上のフレームピクチャ内の透かし模様は、フィールドピクチャのそれと一致する必要がある。これは、フィールドピクチャに使用されたテンプレートからフレームピクチャ用のテンプレートを自動的に導出することにより保証される。これを達成する最も簡単な方法は、フィールドテンプレートの全ての行を２倍にすることである。それにより、フレームテンプレートは、水平１ブロック×垂直２ブロックの有効解像度を持ち、フレームピクチャに表示された透かし模様がフィールドピクチャのそれと確実に一致する。

実際には、ビデオシーケンスは、そのピクチャのタイプの確認がなされる。フィールドのみ及びフレームのみのシーケンスに対しては、そのピクチャタイプに適したテンプレートが用いられる。両方のピクチャタイプを有するシーケンスに対しては、フィールドピクチャに適したテンプレートが選ばれて、そのシーケンス内のフィールドピクチャに使用される。次にフレームピクチャに使用するテンプレートは、そのフィールドテンプレートから導出して透かし模様の外見に矛盾が生じないようにする。

上述のテンプレートは、１つ以上の記録装置に記録されたビットマップであってもよい。

変更
パケット化されたビットストリーム
元のシーケンスがＭＰＥＧ−２パケットストリーム（パケット化ビデオシーケンス又はオーディオ／ビデオマルチプレックス）の場合、透かし模様が埋め込まれたビデオシーケンスが再パケット化されて、残りの透かし模様データがそのパケット化ストリームエンドコードの後に置かれる場合、ビデオシーケンスエンドコードは必要なくなる。

パケット化ストリーム（オーディオ／ビデオマルチプレックス）の埋込みを簡単にするために、そのストリームを前処理してビデオシーケンスを抽出することができる。次に、上述のように、ビデオシーケンスは個別に埋め込みできる。埋め込まれたビデオシーケンスは、テンプレートとして全てのパケット情報の再利用ができ、全てのタイミングを保持する既存のパケット化ストリームファイル（ピクチャデータサイズを維持する通常の副次効果）を使ってオーディオと一緒に再パケット化できる。この追加処理段階は、埋込み処理の操作には必須条件ではないので、上述の擬似コードにおいては説明されていない。

圧縮比の変更
上述の実施の形態では、圧縮ビットストリームに透かし模様データを埋め込む前に、そのビデオは画質を最高にするために最小の圧縮比で圧縮されているものと想定する。よって、透かし模様ユーザデータフィールドが全ての暗号化された元の係数を含むことはなく、残りのデータはファイルの最後に付加される。本発明の別の実施の形態においては、ここではその方法は採らないが、圧縮を実行する前に、透かし模様データを収納するのに必要なデータスペースの推定値を与えて、透かし模様ユーザデータフィールドに元の係数の全部を収め、且つ表示画像データフィールドに新たなＤＣ係数を収めるのに十分な空きスペースを提供するよう圧縮を制御する。

暗号化された原ＡＣ ＶＬＣ及びＤＣ差分の付加
上述の実施の形態においては、透かし模様ユーザデータフィールドに格納される分を超過する原ＡＣ ＶＬＣ及びＤＣ差分は、ファイルの最後に付加される。しかしながら、それらはファイルの最初に置いてもよい。

好ましい実施の形態においては、ファイルの最後に付加された残余のバイト数がカウントされる。そのカウント数はその残余のデータの最後に置かれており、残余のデータのスタートが容易にアクセスできるようにする。

原ＡＣ ＶＬＣ及びＤＣ係数をユーザデータフィールドに格納する他の方法
上述の説明において、原ＡＣ ＶＬＣ及びＤＣ係数は、圧縮ビットストリームのユーザデータフィールド２０に格納される。図１４のフレームＰ１及びＰ２の実施の形態で示したように、フレームＰ１のデータのある部分が、フレームＰ１のユーザデータスペース２０に格納され、それを超える部分がある場合、フレームＰ２のユーザデータスペース２０に格納される。その処理はビットストリーム全体を通じて継続される。残余のデータがある場合、ビットストリームの最後に付加される。

上記処理の他の実施の形態においては、図２９に示すように、フレームＰ１の原ＡＣ ＶＬＣ及びＤＣ差分は、フレームＰ１のユーザデータスペース２０に格納される。全てのフレームに対して、そのフレームのユーザデータスペースに暗号化されたＡＣ ＶＬＣ及びＤＣ差分と一緒に収めきれなかった、それらＡＣ ＶＬＣ及びＤＣ差分のバイト数Ｂからなる残余データフィールド２９１が生成される。残余のＡＣ ＶＬＣ及びＤＣ差分がない場合、そのフレームに対するバイト数Ｂはゼロである。したがって、各フレームはそのユーザデータスペース２０内にはそのフレーム自身のデータだけを納め、残りのデータはどこか他の所へ、例えば、図２９のバッファ２９０に格納する。

上記残余のデータ、すなわちこの実施の形態においては、バッファ２９０のコンテンツは、図３０に示すＭＰＥＧビットストリームの最後に付加してもよい。２９２で示すように、それは、ビットストリームの開始端（End of Start）に付加してもよく、又は２９３で示すように、それは、ビットストリームの終了端の後に付加してもよい。

ユーザデータのビット数を表すコードＢの選択は、ＭＰＥＧビットストリームで使われている他のコードを表すものでないコード、特にＭＰＥＧスタートコードと混乱させないように選ばれる。

ファイル
上述のように、コードＢと暗号化された残余のＡＣ ＶＬＣ及びＤＣ差分とからなる全ての残余のデータは、ビットストリームの最後に付加される。また、他の実施の形態において、その残余のデータは、ビットストリームから分離されたファイルに格納される。そのファイルは、図３０に示すように、ビットストリームの開始端２９２、又は終了端２９３に付加してもよい。図３１に示すように、ファイルは送信媒体２９４、例えばビットストリームから分離されたデータ記録媒体又は通信チャンネルに格納されてもよい。そのデータ記録媒体は、フロッピー（登録商標）ディスク、テープ又はその他の記録媒体であってもよい。

上記ファイルは、そのビットストリームと関連付けられ、一体化される。それは、図３０に示すように、ビットストリームに付加することにより構成されてもよい。ファイルが、図３１に示すように、分離して格納される場合には、例えば、ファイルとビットストリームを結び付ける識別子を使うことにより、そのファイルとビットストリームとを関連付けてもよい。そのような識別子の例としてはＵＭＩＤがある。

洗浄
図２９のビットストリームから透かし模様を洗浄するために、ビットストリームＰ１〜Ｐｎを格納して構文解析を行う。コードＢ、ＡＣ ＶＬＣ及びＤＣ差分からなる残余のデータは、構文解析処理中に、付加されたデータ２９２又は２９３から検索され、又はファイル２９２、２９３又は２９４から取り出されて格納される。各フレームに対し、ユーザデータフィールド２０のデータが復号されて、ビットストリームの変更データを置換するのに使われる。そのフィールドに対するバイト数Ｂが読み出される。それがゼロより大きい場合、次にそのフィールドに対する残余データが復号され、そのフレームの残っている変更データを置換するのに使われる。

ＭＰＥＧビットストリームの例においては、フレームの番号付けは行わず、残余データフィールド２９１の番号付けも行われない。そのような番号付けは不必要であるからである。全てのフレームとそれと関連する残余データフィールドは連続して処理されるからである。そのような番号付けは本発明の他の実施の形態において与えることができる。

透かし模様手法の選択
上述の説明では、３つの透かし模様手法の選択について説明した。しかしながら、以下の項目を含む多くの手法から選択してもよい。
（ａ）変更ＤＣ差分によるＤＣ差分の置換と原ＤＣ差分の取出し
（ｂ）ビットストリーム内に原ＤＣ差分に対するスペースを空けるために、ＡＣ ＶＬＣを取り除く方法
（ｃ）取り外した係数をユーザデータブロックに置く方法
（ｄ）取り外した係数をビットストリームの最後に置く方法
（ｅ）透かし模様を行うための動きベクトルの変更
（ｆ）透かし模様を行うための色情報の変更
（ｇ）Ｐ及び／又はＢフレームの空きスペースに係数を置く方法
これらの手法は、単独又は組み合わせて使ってもよい。例えば、ある場合には、ＡＣ ＶＬＣを取り出さずに、ＤＣ係数だけを変更された係数で置換することも可能である。常時ではないが、一般に、透かし模様のために係数及び動きベクトルを変更すると、ビット数が増加する。

使用する手法は、ビットレートに対するそれらの与える影響に応じて選ばれる。ある特定の手法の組合せの結果、ビット数が大きくなりすぎる場合には（例えば、（ａ）と（ｃ）の組合せ）、別の手法の組合せを選択する。使用する手法は、それを識別するフラグによって、透かし模様が埋め込まれたビットストリーム内で識別されるので、そのビットストリームが透かし模様を取り除くために洗浄装置にかけられるとき、その洗浄装置は正しくその透かし模様を取り除くのに必要な情報が与えられる。

アプリケーション
以上説明した本発明の実施の形態は、次に述べる各状況において適用できる。

コンテンツ仲介（content brokering）
上述の手法を用いて製造される可視透かし模様が埋め込まれたファイルは、規格品ＭＰＥＧ−２プレーヤを使って、コンテンツをプレビューでき（その透かし模様ファイルはＭＰＥＧ−２実証ストリームである）、専用のプレーヤは必要としない。その透かし模様を埋め込んだファイルには、その処理を反転するのに必要な全ての情報が含まれている（暗号化鍵及びテンプレートファイルを除く）。したがって、唯一必要なのはそのコンテンツのコピーを流通／伝送するだけである（従来の手続きでは購買者がそのコンテンツを購入すると、そのシーケンスの保護コピーとそれに続く非保護コピーとを流通する手続きがとられる）。

この流通の形態としては、次のような多くの形態を採ることができる。

透かし模様を埋め込んだコンテンツは安全サーバ上に格納できるが、ファイル内の透かし模様データの暗号化は、ファイルのコピーが請求された時点で行うことができる。顧客は、自分の詳細情報を入力でき、次にそれらは使用された暗号化鍵のコピーと一緒に安全サーバ上に格納される。次に、顧客がそのコンテンツの購入を希望する場合、顧客の詳細情報を索引として使って、暗号化鍵が安全サーバから検索できる。このことは、一人の顧客の暗号化鍵は、別の顧客の透かし模様を埋め込んだコンテンツのコピーを洗浄するのには使えないことを意味する。勿論、それでもその鍵を持つ顧客がコンテンツ（透かし模様を埋め込んだ又は洗浄された）の彼らのコピーを別の人に提供することは可能である。

一旦、顧客がそのコンテンツを購入した場合、次のどちらかのオプションを選べる。すなわち、ファイルを洗浄して可視透かし模様のないファイルを生成するか、又はそのファイルのローカルコピーとして、透かし模様を埋め込んだまま残しておき、必要なときにリアルタイムで洗浄するかのいずれかである。前者の場合は、現在のモデルと変わらないので、受け入れられ易い。

番組毎料金徴収（ペイパービュー）放送
透かし模様処理の特性を生かしたリアルタイム洗浄装置を開発することが可能である。これは、保護されたコンテンツをプレビューのため聴取者に流すことができることを意味する。続いて、聴取者がそのコンテンツに対する支払いを決めると、例えば受信機セットトップボックスに入力する鍵が与えられて、そのコンテンツは受信と同時にローカルに洗浄される。したがって、送信中にそのデータを変更する必要はない。リアルタイム洗浄を迅速容易にするためには、全ての暗号化透かし模様情報を最初にそのセットトップボックスにダウンロードする必要がある。又は、追加の透かし模様データ分を補償する十分なパディングをピクチャフレーム内に含めるように、コンテンツ圧縮処理を変更することもできる。予め定めたテンプレートデザインを用いて、補償が必要とされる最悪の場合の（ビット数）増加分を計算できる。

本発明は、ハードウエア又はソフトウェア若しくはそれらの組合せにより実施してもよ。

本発明は、それがコンピュータ上で実行される場合に、上述の方法を実現するコンピュータプログラムを提供する。本発明は、更にそのようなプログラムを記録した記録装置を提供する。

画像フレームの概要図である。 画像フレーム内の８ｘ８画素ブロックの概要図である。 ＤＣＴブロックの概要図である。 マクロブロックの概要図である。 マクロブロックの行とスライスの概要図である。 画像グループ（ＧＯＰ）の概要図である。 ピクチャデータの１つのフレームの概要図である。 １つのマクロブロックの１ビットストリームの概要図である。 透かし模様を定義するテンプレートの概要図である。 本発明によるＩフレームに適用された透かし模様技術の概要を説明するフローチャートである。 本発明の実施の形態に使用されたデータフォーマットを説明する概要図である。 本発明の実施の形態に使用されたデータフォーマットを説明する概要図である。 本発明の実施の形態に使用されたデータフォーマットを説明する概要図である。 圧縮画像フレーム中に分配されたユーザデータを示す概要図である。 透かし模様暗号化／復号処理のフローチャートである。 本発明による透かし模様取外し方法の概要を説明するフローチャートである。 本発明によるウォータマークシステムを説明する概要図である。 透かし模様取外し装置の概要ブロック図である。 透かし模様埋込み処理及び透かし模様取外し処理に使用された３つのバッファの概要図である。 本発明による非Ｉフレームに適用された透かし模様方法の概要を説明するフローチャートである。 （ａ）は透かし模様を埋め込んだマクロブロックを示し、（ｂ）はＤＣＴタイプ変更処理のフローチャートである。 手法選択処理のフローチャートである。 動きベクトルと一緒に使用されるテンプレートを示す図である。 本発明の実施の形態における動きベクトルコードに適用された方法の概要を説明するフローチャートである。 動きベクトルの符号化を説明する図である。 ビデオシーケンスのフレームピクチャへの透かし模様埋込みを説明する図である。 ａ）ビデオシーケンスのフィールドピクチャへの透かし模様埋込みを説明する図であり、ｂ）ビデオシーケンスのフィールドピクチャ及びフレームピクチャへの透かし模様埋込みを説明する図である。 インタレースされたフィールド及びフレームに対する透かし模様埋込みマクロブロックを説明する図である。 本発明の変更例を示す図である。 本発明の変更例を示す図である。 本発明の変更例を示す図である。

Claims (53)

1. ピクチャ情報を表すデジタルコードを含むビットストリームを変更するビットストリームの変更方法において、
   透かし模様を埋め込むピクチャの該透かし模様の部分に対応するデジタルコードであって、上記ピクチャ情報の変更を表す少なくとも１つの変更コードが含まれることになる上記ビットストリームの一部分を占める少なくとも１つのデジタルコードを選択するステップと、
   上記ビットストリームの一部分から、上記選択されたデジタルコードを取り外すステップと、
   上記選択されたデジタルコードの代わりに、上記少なくとも１つの変更コードを、上記ビットストリームの一部分に挿入するするステップとを有し、
   上記選択され、取り外されたデジタルコードのビット数は、上記ビットストリームに挿入された上記変更コードのビット数以上であり、
   上記ピクチャ情報を表すデジタルコードは、該ピクチャ情報のＤＣＴ係数を表すコードであり、
   上記ＤＣＴ係数は、ＤＣ係数及びＡＣ係数を含み、
   上記ビットストリームは、上記ビットストリームの一部分から、（１）ＡＣ係数を表すＡＣコードを取り外す技術及び（２）ＤＣ係数を表すＤＣコードを取り外す技術のうち少なくとも１つによって変更可能であり、
   当該ビットストリームの変更方法は、
   上記ＤＣコードをＤＣ係数の変更コードで置換し、上記選択され、取り外されたデジタルコードを、（ａ）上記ビットストリームと関連付けて格納し、及び／又は（ｂ）上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置するステップと、
   上記ビットストリームの試行変更を実行するステップと、
   上記試行変更の上記ビットストリームのビット数に対する影響を評価するステップと、
   上記評価に基づいて、上記ビットストリームの変更を実行するための１つ以上の上記技術を選択するステップとを更に有することを特徴とするビットストリームの変更方法。
2. 上記選択され、取り外されたデジタルコードを、上記取外しコードデータフィールドに再分配するステップと、
   上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて、好ましい順序で格納するステップとを更に有し、
   上記好ましい順序は、（１）上記取外しコードデータフィールドに格納し、（２）上記選択され、取り外されたデジタルコードを、上記ビットストリームに関連付けて格納することを特徴とする請求項１に記載のビットストリームの変更方法。
3. 上記選択され、取り外されたデジタルコードの幾つかを、上記ビットストリームと関連付けて格納するステップと、
   上記選択され、取り外されたデジタルコードの残りを、上記１つ以上の取外しコードデータフィールド内に配置するステップとを更に有する請求項１に記載のビットストリームの変更方法。
4. 上記選択され、取り外されたデジタルコードを上記ビットストリームと関連付けて格納するステップ（１）では、上記選択され、取り外されたデジタルコードを、上記ビットストリームの端に付加することを特徴とする請求項１に記載のビットストリームの変更方法。
5. 上記選択され、取り外されたデジタルコードを上記ビットストリームと関連付けて格納するステップ（１）では、上記選択され、取り外されたデジタルコードをファイルに格納することを特徴とする請求項１に記載のビットストリームの変更方法。
6. 上記ファイルは、上記ビットストリームの端に付加されることを特徴とする請求項５に記載のビットストリームの変更方法。
7. 上記ファイルは、上記ビットストリームの開始端に付加されることを特徴とする請求項６に記載のビットストリームの変更方法。
8. 上記ファイルは、上記ビットストリームから分離されるとともに、該ビットストリームと関連付けられていることを特徴とする請求項５に記載のビットストリームの変更方法。
9. 上記選択され、取り外されたデジタルコードの全てを、上記ビットストリームの最後に付加するステップを更に有する請求項１に記載のビットストリームの変更方法。
10. 上記選択され、取り外されたデジタルコードの全てを、上記１つ以上の取外しコードデータフィールド内に配置するステップを更に有する請求項１に記載のビットストリームの変更方法。
11. 当該ビットストリームの変更方法によって生ずるピクチャ情報に関連付けられたデータの増加量を判定するステップと、
    上記判定されたデータの増加量によって必要とされる空き容量を提供するように、望ましいビットレートで元のピクチャの圧縮を制御するステップとを更に有する請求項１０に記載のビットストリームの変更方法。
12. 上記変更されたビットストリームのビットレートが元のビットストリームに対して変わらないように、該変更されたビットストリームにパディングビットを加えるステップを更に有する請求項１に記載のビットストリームの変更方法。
13. 上記変更コードが含まれることになるビットストリームの一部分又は複数の部分を定義するために、テンプレートを用いるステップを更に有する請求項１に記載のビットストリームの変更方法。
14. 上記ビットストリームの同じ部分から取り外されたデジタルコードは、グループコードで識別されるグループにグループ分けされることを特徴とする請求項１に記載のビットストリームの変更方法。
15. 上記ビットストリームの一部分は、少なくとも１つのＤＣＴブロックであることを特徴とする請求項１４に記載のビットストリームの変更方法。
16. 上記ビットストリームは、少なくともイントラ符号化ピクチャを含むビデオビットストリームであり、
    上記イントラ符号化ピクチャ上で実行されることを特徴とする請求項１に記載のビットストリームの変更方法。
17. 上記ビットストリームは、インター符号化ピクチャを含み、
    上記インター符号化ピクチャ上で実行されることを特徴とする請求項１６に記載のビットストリームの変更方法。
18. 上記インタ符号化ピクチャは、ＤＣ係数を表すＤＣコードを含み、
    当該ビットストリームの変更方法は、
    上記ＤＣコードのうちの選択されたものを取り外すステップと、
    上記取り外されたＤＣコードを、上記ビットストリームと関連付けて格納し、及び／又は上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置するステップと、
    上記取り外されたＤＣコードを所定値の変更コードで置換するステップとを更に有する請求項１７に記載のビットストリームの変更方法。
19. 上記インター符号化ピクチャ内のＤＣ係数を表す上記ＤＣコードは、量子化された変更値を表し、
    上記所定値は、ゼロより大きな最小の変更の有効値を表すことを特徴とする請求項１８に記載のビットストリームの変更方法。
20. 上記所定値は、±１であることを特徴とする請求項１９に記載のビットストリームの変更方法。
21. 上記インター符号化ピクチャは、動きベクトルを表すコードを含み、
    当該ビットストリームの変更方法は、
    上記変更コードが含まれることになるビットストリームの部分に関連する上記動きベクトルを取り外すステップと、
    元の動きベクトルコードを、ゼロ動きベクトルを表す動きベクトル変更コードで置換するステップと、
    上記取り外された動きベクトルコードを、上記ビットストリームの最後に付加し、及び／又は該取り外された動きベクトルコードを、上記ビットストリーム内の取外しコードデータフィールド内に配置するステップとを更に有する請求項１７に記載のビットストリームの変更方法。
22. 上記変更コードが含まれることになるビットストリームの部分にピクチャ内で隣接するインター符号化ピクチャの部分に関連する動きベクトルコードを取り外すステップと、
    上記インター符号化ピクチャの部分に関連する元の動きベクトルコードを、ゼロ動きベクトルを表す動きベクトル変更コードで置換するステップと、
    上記取り外された動きベクトルコードを、上記ビットストリームの最後に付加し、及び／又は該取り外された動きベクトルコードを、上記ビットストリーム内の取外しコードデータフィールド内に配置するステップとを更に有する請求項２１に記載のビットストリームの変更方法。
23. 上記変更されるイントラ符号化ピクチャのブロックを定義する第１のテンプレートと、該第１のテンプレートのブロックに対応するインター符号化ピクチャのブロックを定義する第２のテンプレートとを提供するステップを更に有し、
    上記インター符号化ピクチャのブロックに関連する動きベクトルは、ゼロに設定されることを特徴とする請求項２１に記載のビットストリームの変更方法。
24. 上記第２のテンプレートは、上記関連する動きベクトルがゼロに設定される上記ブロックを含むマクロブロックを定義することを特徴とする請求項２３に記載のビットストリームの変更方法。
25. 上記第２のテンプレートは、上記マクロブロックと境界を接する更なるマクロブロックを定義し、
    上記更なるマクロブロックに関連する動きベクトルは、ゼロに設定されることを特徴とする請求項２４に記載のビットストリームの変更方法。
26. 上記ビットストリームは、符号化のタイプを示すタイプコードによって、フィールドタイプ又はフレームタイプとして符号化可能なＤＣＴブロックを含み、
    当該ビットストリームの変更方法は、
    上記フィールドタイプを示す上記タイプコードのうちの選択されたものを取り外すステップと、
    上記取り外されたタイプコードを、上記フレームタイプを示す変更タイプコードで置換するステップと、
    上記取り外されたタイプコードを、上記ビットストリームと関連付けて格納し、及び／又は該取り外されたタイプコードを、該ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置するステップとを更に有する請求項１６に記載のビットストリームの変更方法。
27. 上記ビットストリームは、ＭＰＥＧ２ビットストリームであることを特徴とする請求項１に記載のビットストリームの変更方法。
28. 上記変更コードが含まれることになる上記ビットストリームの部分を示すデータを提供するステップを更に有する請求項１に記載のビットストリームの変更方法。
29. 上記ビットストリームは、補助データフィールドを含み、
    当該ビットストリームの変更方法は、上記補助データフィールドから取り外されたコードのデータフィールドを識別するデータを上記ビットストリーム内に提供するステップを更に有する請求項２７又は２８に記載のビットストリームの変更方法。
30. 上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連させて格納し、及び／又は該選択され、取り外されたデジタルコードを上記取外しコードデータフィールド内に配置する前に、暗号化するステップを更に有する請求項１に記載のビットストリームの変更方法。
31. 上記ピクチャ情報は、ビデオデータ、オーディオデータ、ビジュアルデータ、及びこれら以外のデータのうちの１つ以上を含むことを特徴とする請求項１に記載のビットストリームの変更方法。
32. 上記変更は、上記ピクチャ情報により表される情報において視認可能な効果を生ずることを特徴とする請求項１に記載のビットストリームの変更方法。
33. プロセッサで実行されたときに、該プロセッサに、請求項１に記載のビットストリームの変更方法の各ステップを実行させるためのコンピュータプログラム。
34. 請求項３３に記載のコンピュータプログラムを記録した記録媒体。
35. ピクチャ情報を表すデジタルコードを含むビットストリームを変更するビットストリームの変更装置において、
    透かし模様を埋め込むピクチャの該透かし模様の部分に対応するデジタルコードであって、上記ピクチャ情報内で視認可能な変更を表す少なくとも１つの変更コードが含まれることになる上記ビットストリームの一部分を占有する少なくとも１つのデジタルコードを選択する選択手段と、
    上記ビットストリームの一部分から、上記選択されたデジタルコードを取り外す取外し手段と、
    上記選択されたデジタルコードの代わりに、上記変更コードを、上記ビットストリームの一部分に配置する変更コード配置手段とを備え、
    上記選択され、取り外されたデジタルコードのビット数は、上記ビットストリームに配置された変更コードのビット数以上であり、
    上記デジタルコードは、上記ピクチャ情報のＤＣＴ係数を表し、
    上記ＤＣＴ係数は、ＤＣ係数及びＡＣ係数を含み、
    上記取外し手段は、上記ビットストリームの一部分から、（１）ＡＣ係数を表すＡＣコードを取り外す技術及び（２）ＤＣ係数を表すＤＣコードを取り外す技術の少なくとも１つを実行可能であり、
    上記変更コード配置手段は、上記取り外されたＤＣコードを変更ＤＣコードで置換し、
    上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて格納し、及び／又は上記上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置し、
    当該ビットストリームの変更装置は、
    上記ビットストリームの試行変更を実行し、該試行変更の該ビットストリームのビット数に対する影響を評価し、該評価に基づいて、１つ以上の上記技術を選択する手段を更に備えることを特徴とするビットストリームの変更装置。
36. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードを、上記取外しコードデータフィールドに再分配し、上記選択され、取り外されたデジタルコードを好ましい順序で上記ビットストリームと関連付けて格納し、
    上記好ましい順序は、（１）上記取外しコードデータフィールドに格納し、（２）上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて格納することを特徴とする請求項３５に記載のビットストリームの変更装置。
37. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードの幾つかを、上記ビットストリームと関連付けて格納し、上記選択され、取り外されたデジタルコードの残りを、上記１つ以上の取外しコードデータフィールド内に配置することを特徴とする請求項３５に記載のビットストリームの変更装置。
38. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードを、上記ビットストリームの端に付加することによって、（１）上記選択され、取り外されたデジタルコードを、該ビットストリームと関連付けて格納することを特徴とする請求項３５に記載のビットストリームの変更装置。
39. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードをファイルに格納することによって、（１）上記選択され、取り外されたデジタルコードを、上記ビットストリームと関連付けて格納することを特徴とする請求項３５に記載のビットストリームの変更装置。
40. 上記取外しコード配置手段は、上記ファイルを上記ビットストリームの端に付加することを特徴とする請求項３９に記載のビットストリームの変更装置。
41. 上記取外しコード配置手段は、上記ファイルを上記ビットストリームとは分離し、該ビットストリームと関連付けて格納することを特徴とする請求項３９に記載のビットストリームの変更装置。
42. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードの全てを、上記ビットストリームの最後に付加することを特徴とする請求項３５に記載のビットストリームの変更装置。
43. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードの全てを、上記１つ以上の取外しコードデータフィールド内に配置することを特徴とする請求項３５に記載のビットストリームの変更装置。
44. 上記取外しコード配置手段は、上記選択され、取り外されたデジタルコードを、上記ビットストリームの最後に付加し、及び／又は該選択され、取り外されたデジタルコードを、上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置することを特徴とする請求項４３に記載のビットストリームの変更装置。
45. 上記ビットストリームは、少なくともイントラ符号化ピクチャを含み、
    当該ビットストリームの変更装置は、上記イントラ符号化ピクチャを変更することを特徴とする請求項３５に記載のビットストリームの変更装置。
46. 上記ビットストリームは、インター符号化ピクチャを含み、
    当該ビットストリームの変更装置は、更に上記インター符号化ピクチャを変更することを特徴とする請求項４５に記載のビットストリームの変更装置。
47. 上記インター符号化ピクチャは、ＤＣ係数を表すコードを含み、
    当該ビットストリームの変更装置は、
    上記ＤＣコードのうちの選択されたものを取り外す手段と、
    上記取り外されたＤＣコードを、上記ビットストリームと関連付けて格納し、及び／又は上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置する手段と、
    上記取り外されたＤＣコードを所定値の変更コードで置換する手段とを更に備える請求項４６に記載のビットストリームの変更装置。
48. 上記インター符号化ピクチャ内のＤＣ係数を表すコードは、量子化された変更値を表し、
    上記所定値は、ゼロより大きな最小の変更の有効値を表すことを特徴とする請求項４７に記載のビットストリームの変更装置。
49. 所定値は、±１であることを特徴とする請求項４８に記載のビットストリームの変更装置。
50. 上記インター符号化ピクチャは、動きベクトルを表すコードを含んでおり、
    上記変更コードが含まれることになるビットストリームの部分に関連する動きベクトルコードを取り外し、元の動きベクトルコードをゼロ動きベクトルを表す動きベクトル変更コードで置換し、該取り外された動きベクトルコードを、該ビットストリームと関連付けて格納し、及び／又は該取り外された動きベクトルコードを、該ビットストリーム内の取外しコードデータフィールド内に配置する動きベクトルコード取外し手段を更に備える請求項４６に記載のビットストリームの変更装置。
51. 上記動きベクトルコード取外し手段は、上記変更コードが含まれることになるビットストリームの部分にピクチャ内で隣接するインター符号化ピクチャの部分に関連する動きベクトルコードを取り外し、該インター符号化ピクチャの部分に関連する元の動きベクトルコードを、ゼロ動きベクトルを表す動きベクトル変更コードで置換し、該取り外された動きベクトルコードを、上記ビットストリームと関連付けて格納し、及び／又は該取り外された動きベクトルコードを、上記ビットストリーム内の取外しコードデータフィールド内に配置することを特徴とする請求項５０に記載のビットストリームの変更装置。
52. 上記ビットストリームは、符号化のタイプを示すタイプコードによって、フィールドタイプ又はフレームタイプとして符号化されるＤＣＴブロックを含み、
    当該ビットストリームの変更装置は、
    上記フィールドタイプを示すタイプコードのうちの選択されたものを取り外す手段と、
    上記取り外されたタイプコードを、上記フレームタイプを示す変更タイプコードで置換する手段と、
    上記取り外されたタイプコードを、上記ビットストリームと関連付けて格納し、及び／又は該取り外されたタイプコードを、上記ビットストリーム内の１つ以上の取外しコードデータフィールド内に配置する手段とを更に備える請求項３５に記載のビットストリームの変更装置。
53. 上記ピクチャ情報は、ビデオデータ、オーディオデータ、ビジュアルデータ、及びこれら以外のデータのうちの１つ以上を含むことを特徴とする請求項３５に記載のビットストリームの変更装置。

Images