(57)【特許請求の範囲】
【請求項１】
方法であって、
ＣＡＢＡＣ符号化データにアクセスする工程と、
前記符号化データの構文要素に適用可能な変更のリストを生成する工程であって、前記構文要素が、前記符号化データの動きベクトル差分のサフィックスである工程と、
元の符号化データの前記構文要素の符号化に関連付けられた符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの値にアクセスする工程と、
前記リストにおける前記変更毎に、前記変更された符号化データの前記構文要素の符号化に関連付けられた符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの値にアクセスする工程と、
前記リストにおける前記変更毎に、前記元の符号化データと、前記変更された符号化データとの間で、符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの値を比較する工程と、
前記符号化データに適用された場合、定義された少なくとも１つの基準を満たさない変更を除外し、それにより、フィルタリングされた変更のフィルタリングされたリストを生成する工程であって、前述の１つの基準は、変更された符号化データ及び前記元の符号化データにより、ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの同じそれぞれの値が生成されるための基準である工程と、
前記フィルタリングされたリストにおける前記フィルタリングされた変更の少なくとも１つを前記符号化データに適用する工程とを含む方法。
【請求項２】
請求項１記載の方法であって、前記変更が透かしである方法。
【請求項３】
請求項１記載の方法であって、前記定義された少なくとも１つの基準は、前記変更が適用された場合に可視アーチファクトがないことである方法。
【請求項４】
請求項１記載の方法であって、
前記符号化データに対する前記変更の動きベクトル差分サフィックス範囲を求める工程を更に含み、前記範囲は、特定のビット長について考えられる値全てである方法。
【請求項５】
請求項４記載の方法であって、
少なくとも１つの現在のブロックに対する前記変更のビット長と、前記少なくとも１つの現在のブロックのビット長とを比較する工程と、
前記少なくとも１つの現在のブロックの前記ビット長に等しくないビット長をもたらす変更を除外する工程とを含む方法。
【請求項６】
方法であって、
ＣＡＢＡＣ符号化ビデオ・データにアクセスする工程と、
前記ビデオ・データに対する透かしのリストを生成するか、又は編集する工程と、
前記透かしを有する現在のブロックの構文要素及びビデオ・データの現在のブロックの構文要素を求める工程であって、前記構文要素が、前記符号化ビデオ・デ―タの動きベクトル差分のサフィックスである工程と、
前記透かしを有する前記現在のブロック及び前記ビデオ・データの現在のブロックに関連付けられた符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの値にアクセスする工程と、
前記リストにおける前記透かし毎に、前記透かしを有する前記現在のブロック及び前記ビデオ・データの現在のブロックとの間で、符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇの値を比較する工程と、
前記透かしを有する前記現在のブロックと、前記ビデオ・データの現在のブロックとの間での、符号化変数ｃｏｄＩＬｏｗ及びｂｉｔｓＯｕｔｓｔａｎｄｉｎｇにおける差に基づいて透かしを除外する工程とを含む方法。
【請求項７】
請求項６記載の方法であって、
前記除外する工程は更に、
前記リストからの透かしを有する前記現在のブロック、及び前記ビデオ・データの現在のブロックのビット長を求める工程と、
前記リストからの透かしを有する前記現在のブロック、及び前記ビデオ・データの現在のブロックのビット長を比較する工程と、
前記現在のブロックの前記ビット長に等しくないビット長をもたらす透かしを除外する工程とを含む方法。
【請求項８】
請求項６記載の方法であって、前記除外する工程が更に、
前記現在のブロックに適用された場合、アーチファクトをもたらす、許容された透かしを除外し、それにより、フィルタリングされた許容された透かしの更にフィルタリングされたリストをもたらす工程とを含み、前記データが、ＣＡＢＡＣ符号化されたビデオ・ストリームである方法。
【請求項９】
請求項６記載の方法であって、前記生成する工程が、
前記構文要素の特定の元の値の有効な別の後部サフィックス値を収集する工程を含み、
前記値にアクセスする工程が、
前部サフィックスの元の値を符号化する工程と、
元の後部サフィックスの符号化前に符号化変数状態を保存する工程と、
後部サフィックスの元の値を符号化する工程と、
後部サフィックスの元の値を符号化した後の新たな符号化変数状態を保存する工程と、
考えられる後部サフィックスの別の値全てを巡回させる工程と、
元の後部サフィックスの符号化前の符号化変数状態に等しく、考えられる後部サフィックスの別の値それぞれの前の符号化変数状態を設定する工程と、
前記後部サフィックスの別の値を符号化する工程とを含み、
前記比較する工程は、
元の値の符号化後の状態、及び後部サフィックスの別の値の符号化後の状態を比較する工程を含み、
前記除外する工程は、
前記元の値の符号化後の状態及び前記別の値の符号化後の状態が異なる場合に、透かしを前記リストから除外する工程を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（相互参照）
本特許出願は、「ＣＨＡＮＧＥＡＢＬＥ  ＢＬＯＣＫ  ＬＩＳＴ」と題する、西暦２００８年８月１９日付出願の米国特許仮出願第６１／１８９４３０号の利益及び優先権を主張する。上記仮出願は、全ての目的でその全体を参照により、本明細書及び特許請求の範囲において明示的に援用する。
【０００２】
（技術分野）
本発明は、圧縮ビデオ・ストリームに施すことが可能な許容可能な透かしのリストを生成する方法に関する。
【背景技術】
【０００３】
今日では、海賊行為阻止手法としてのディジタル透かし入れに対する需要は大きい。
海賊行為者が透かしを出し抜くことをより困難にするために、多くの潜在的な透かしが、提案され、使用されることが重要である。しかし、意図された視聴者にとって、意図された視聴体験を透かしが妨げることのないようにすることが重要である。そういうものとして、更に効率的な透かし入れ手法に対する必要性が存在している。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
そういうものとして、本発明の目標は、ＣＡＢＡＣ／ＡＶＣ（コンテキスト・ベースの適応的２進算術符号化／高度ビデオ圧縮）準拠であり、未だ、可視アーチファクトを生成しない、透かし入れに概括的に関連付けられた考えられる変更のリストを生成することである。
【課題を解決するための手段】
【０００５】
許容可能な透かしのリストを生成する方法は、符号化データにアクセスする工程と、符号化データに対する変更のリストにアクセスし、又は、上記リストを生成し、若しくは編集する工程と、要件を満たさない、例えば、アーチファクトをもたらす変更を除外し、それにより、フィルタリングされた変更のフィルタリングされたリストを生成する工程と、フィルタリングされたリストにおけるフィルタリングされた変更のうちの少なくとも１つを符号化リストに施す工程とを含む。符号化データは、ＣＡＢＡＣ符号化されたＨ．２６４／ＡＶＣビデオ・ストリームにあり得る圧縮ビデオ・データであり得る。フィルタリングされた変更は、許容可能な透かしであり得る。上記方法は、少なくとも１つの参照ブロックに対する動きベクトル差分を求める工程、及び少なくとも１つの参照ブロックに対する少なくとも１つの現在のブロックの動きベクトル差分を求める工程を含み得る。動きベクトル差分の比較は、変更をリストから除外するために使用することが可能である。上記方法は、現在のブロックに対する変更及び現在のブロックの構文要素を求める工程と、少なくとも３つのカテゴリ（第１のカテゴリは、ゼロに等しい値の場合であり、第２のカテゴリは、ゼロを上回り、最大値を下回る値の場合であり、第３のカテゴリは、第２のカテゴリにおける値を上回る値、乃至最大値の場合である）に動きベクトル差分値を設定する工程とを含み得る。更に、上記方法は、第２のカテゴリにおける動きベクトル差分値の構文要素にプリフィックス値を施す工程、及び第２のカテゴリにおける動きベクトル差分値の構文要素にサフィックス値を施す工程を含み得る。更に、上記方法は、現在のブロックに対する変更及び現在のブロックの符号化変数範囲を求める工程であって、符号化変数範囲は、特定のビット長について考えられる値である工程と、現在のブロックの動きベクトル差分値に対する変更の符号化変数範囲を比較する工程と、現在のブロックの動きベクトル差分値を含まない符号化変数範囲を有する変更をフィルタリングする工程と、現在のブロックに対する変更及び現在のブロックのビット長を求める工程とを含み得る。方法は、現在のブロックに対する変更、及び現在ブロックのビット長を比較する工程と、現在のブロックのビット長に等しくないビット長を有する変更をフィルタリングする工程であって、ビット長に基づいた変更のフィルタリングは、符号化変数の判定に基づいたフィルタリングと組み合わせて行うことが可能である工程とを含み得る。
【０００６】
ビデオ・データにアクセスする工程と、ビデオ・データに対する考えられる変更又は透かしのリストにアクセスし、又は前記リストを生成する工程と、透かしを有する現在のブロックの構文要素及び現在のブロックの構文要素を判定する工程と、透かしを有する現在のブロック及び現在のブロック間の構文要素における差に基づいて透かしを除去し、それにより、許容された透かしのフィルタリングされたリストを生成する工程とを含む方法を行うよう適合されたＣＡＢＡＣ符号化エンジン等が提供される。エンジン等における除去工程は、更に、（１）リストからの透かしを有する現在ブロック及び現在ブロックの符号化変数範囲を求める工程と、リストからの透かしを有する現在のブロック及び現在のブロックの符号化変数範囲を比較する工程と、現在のブロックの符号化変数範囲外の範囲の符号化変数範囲をもたらす透かしを除去する工程を含み、（２）リストからの透かしを有する現在のブロック及び現在のブロックのビット長を求める工程と、リストからの透かしを有する現在のブロック及び現在のブロックのビット長を比較する工程と、現在のブロックのビット長に等しくないビット長をもたらす透かしを除去する工程とを含む。現在のブロックに施されると、十分にロバストでないか、又は、アーチファクトをもたらす許容可能な変更を除去する更なる除去工程を使用することが可能である。
【図面の簡単な説明】
【０００７】
【図１】符号化のシミュレーション、及び有効な別のｍｖｄの後部サフィックス値の収集物を示す、本発明によるブロック図である。
【図２】符号化器ベースのＣＢＣシステム・アーキテクチャを示す図である。
【図３】トランスコーダ・ベースの枠組みを示す図である。
【発明を実施するための形態】
【０００８】
次に、本発明は、添付図面を参照して、例により、説明する。
【実施例】
【０００９】
次に、本発明の実施例は、一般に、ＣＡＢＡＣ符号化Ｈ．２６４／ＡＶＣビデオ・ストリームのコンテキスト内で説明する。しかし、実施例は、より広い適用例を有し得る。
【００１０】
ＣＡＢＡＣ符号化Ｈ．２６４／ＡＶＣビデオ・ストリームは、符号化動きベクトル差分  （ｍｖｄ）を含み得る。Ｈ．２６４では、画素値の多くのブロックは、まず、先行して符号化されたデータからその値を予測し、次いで、この予測と実際の値との間の差を符号化することによって符号化される。インター予測と呼ばれる予測の一手法は、参照フレームと呼ばれる別のフレームにおけるデータの同様な大きさのブロックから現在のブロックを予測する。前述の参照ブロックは、現在のブロックの位置と比較した参照ブロックの水平方向及び垂直方向のオフセットを示す動きベクトルの組及び参照フレームのインデクスによって識別される。
【００１１】
隣接ブロックの動きベクトルは、互いに相関化することが可能である。前述の相関を活用するために、Ｈ．２６４は動きベクトルに対して予測符号化を施すことが可能である。一ブロックの動きベクトルは、まず、先行して符号化されたデータからその値を予測し、次いで、この予測と実際の動きベクトル値との間の差を符号化することによって符号化される。
【００１２】
動きベクトル差分（ｍｖｄ）と呼ばれる前述の差は、少なくとも１つの実現形態の主眼である。これは、構文要素の例でもある。
【００１３】
動きベクトル差分値０は単に、２進シンボル０で表す。前述の０は、コンテキスト・インデクスとともにＣＡＢＡＣ書き込み装置に送出される。ＣＡＢＡＣ書き込み装置はコンテキスト及び２進シンボルを入力として使用し、コンテキストを修正する。なお、ゼロ値ｍｖｄを示す前述のシンボル０の符号化が、ＣＡＢＡＣコンテキストに影響を受け、同様に、ＣＡＢＡＣコンテキストに影響を及ぼす。他のｍｖｄは全て、符号及び大きさで表される。大きさがまず符号化され、符号はこれに続く。大きさが１と８との間の動きベクトル差分は、ｍｖｄプリフィックスと呼ばれる単一の値で符号化することが可能である。より大きなｍｖｄもｍｖｄサフィックスを必要とする。前述の２つの値は後述するように別個に符号化される。
【００１４】
ｍｖｄプリフィックスの符号化に関し、ｍｖｄｍと呼ばれる新たな値はａｂｓ（ｍｖｄ）−１として定義される。０乃至７の間のｍｖｄｍの値の場合、ｍｖｄｍは、プリフィックスにおいて続く２進数１のシンボルの数を示す。前述の１のシンボルは、２進数０のシンボルで終了する。ｍｖｄｍが８以上の値の場合、１のシンボルが８つ、プリフィックスに書き込まれ、プリフィックスには、サフィックスが後続する。ｍｖｄプリフィックスの符号化は表１に要約する。
【００１５】
【表１】
0005373909.tif 000002
0005373909.tif 000003
大きさ９以上のｍｖｄは、前述の値が、符号化される対象のｍｖｄサフィックスも有する旨を示すオール１のプリフィックスを有する。ｍｖｄプリフィックスにおけるシンボルはそれぞれ、対応するコンテキスト・インデクスとともにＣＡＢＡＣ書き込み装置に送出される。
【００１６】
ｍｖｄサフィックスの符号化に関し、大きさ９以上のｍｖｄは全て、符号化される対象のｍｖｄサフィックスを必要とする。サフィックスは、値ｍｖｄｍ−８を符号化する。前述の符号化は、デコードバイパス・モードで行われる（Ｈ．２６４技術仕様、表９−２５、ＩＴＵ−Ｔ  Ｈ．２６４標準：  Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ、２００５／０３を参照されたい）。前述のモードは、等確率ＥｘＧｏｌｏｍｂ（ＥｐＥｘＧｏｌｏｍｂ）符号化を使用する。ＥｐＥｘＧｏｌｏｍｂの重要な局面は、ＣＡＢＡＣ書き込み装置によって使用されるコンテキストがないという点である。同様に、シンボルのＣＡＢＡＣ書き込みによって影響を受けるコンテキストがない。このことの示唆は、上述の出願に記載の通り、ＣＡＢＡＣ又はＡＶＣ復号化誤差を何らもたらさずに、等しい長さで別の値にｍｖｄサフィックスを変更することが可能であり得るという点である。
【００１７】
ｍｖｄサフィックスは、ｍｖｄの絶対値が９を超える量を符号化するために使用される。これは、ｍｖｄｍ−８として表すことが可能である。前述の差は２進化され、２進シンボルは、ＥｐＥｘＧｏｌｏｍｂ書き込み装置に送出される。
【００１８】
サフィックスの２進化は表２において要約する。ここで、ｘｘｘはｍｖｄｍの標準的な二進表現を表す。
【００１９】
【表２】
0005373909.tif 000004
ｍｖｄの大きさの二進化処理全体を表３に要約する。  
【００２０】
【表３】
0005373909.tif 000005
ＣＡＢＡＣ符号化Ｈ．２６４／ＡＶＣ符号化ストリームを修正するための１つ又は複数の実現形態が存在し得る。前述の少なくとも１つの実現手段は、２つのステップ（すなわち、変更のリストが生成される解析段階、及び変更が施される埋込段階）を伴う。解析段階は、リスト・フィルタリング処理の組が後続するリスト生成処理としておおよそ表すことが可能である。大きな問題は、リスト生成処理にある。前述の処理の出力は変更のリストであり、その何れも、ビットストリームのＡＶＣ／ＣＡＢＡＣ準拠性を妨げることなく、行うことが可能である。フィルタリング動作は、可視アーチファクトをもたらす変更を除去し、復元が難しくなる変更を除去し、ペイロード制約や他のアプリケーション制約などの外部の他の制約に準拠する変更の組を生成するよう企図される。そういうものとして、実施例は、リスト生成処理の実現形態に対処し、ＣＡＢＡＣ算術符号化器の一部分を使用して、有効な別の動きベクトル差分の後部サフィックスを識別する。
【００２１】
別のＭＶＤ収集物を伴う一例では、有効な別の動きベクトル差分の後部サフィックスの識別の全部又は一部は、前述のＥｐＥｘＧｏｌｏｍｂ符号化を行う機能の内部で実現される。この場合において特に関心があるのは、前述の機能が、ｍｖｄサフィックス値を符号化するために呼び出されることである。
【００２２】
サフィックス値毎に、ＣＡＢＡＣ又はＡＶＣ構文を妨げることなく、置き換えることが可能な別のサフィックス値を求めてサーチする。透かし入れの処理の前述の部分の目標は、ＣＡＢＡＣ／ＡＶＣ準拠のままである、考えられる変更全てのリストを生成することである。後に、前述のリストは他の基準によってフィルタリングすることが可能である。まず、ＣＢＣ（変更可能なブロック収集物）として別の値を収集する処理が定義される。ＣＢＣという語は、別のｍｖｄの大きさの値を識別する処理を表すために使用される。
【００２３】
表２及び表３から、全てが同じ２進化長につながるｍｖｄの範囲が存在することが分かり得る。例えば、１７乃至３２のｍｖｄの大きさは全て、１６個のシンボル、１０個のプリフィックス・シンボル、及び６個のサフィックス・シンボルを含む２進化値を有する。８を上回る大きさの特定のｍｖｄの場合、同じ２進長を有する他のｍｖｄの組が存在している。組における前述の他のｍｖｄ大きさそれぞれは、特定のｍｖｄ大きさの潜在的な別の値である。本願に開示する方法は、一度に１つ、前述の他のｍｖｄそれぞれを検査して、別の値としてその適切性を判定する。前述の判定は、符号化変数及び符号化ビット長に基づく。特に、検査される符号化変数は、「ｃｏｄＩＬｏｗ」及び「ｂｉｔｓＯｕｔｓｔａｎｄｉｎｇ」である。これは、ＩＴＵ−Ｔ  Ｈ．２６４標準Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ、  ２００５／０３のＨ．２６４仕様、図９乃至図１０を参照することにより、よりよく理解することが可能である。
【００２４】
上記例では、範囲１７乃至３２におけるｍｖｄの大きさの場合、サフィックスが６シンボルを有するということを述べた。しかし、最初の２つのシンボルは、範囲内の組全体について１０に固定される。最後の４シンボルのみが異なり得る。少なくとも１つの実際の実現形態は前述の２つの部分を別々に扱う。サフィックスの固定部分は前部サフィックスとして定義され、変数部分は後部サフィックスとして定義される。範囲９−１６における８ｍｖｄの大きさの場合、後部サフィックスは３シンボル長である。範囲１７−３２における１６ｍｖｄの大きさの場合、後部サフィックスは４シンボル長である。
【００２５】
上記方法はＣＡＢＡＣ書き込み装置をブラック・ボックスとして扱う。潜在的な別の値はＣＡＢＡＣ書き込み装置への入力として供給され、符号化ビット長、及び符号化変数に対する影響を観測又は考慮することが可能である。これらが、元の値で得られたものと同じである場合、別の値が、有効な代替値として受け入れられ、リストに保存される。さもなければ、これは、有効な代替値でなく、保存されない。
【００２６】
符号化変数「ｂｉｔＯｕｔｓｔａｎｄｉｎｇ」は、ＩＴＵ−Ｔ  Ｈ．２６４標準：Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ、２００５／０３のＨ．２６４／ＡＶＣ仕様（図９−１０）による、バイパス符号化処理において利用可能である一方，ＩＴＵ−Ｔ  Ｈ．２６４標準：Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ、２００５／０３のＨ．２６４／ＡＶＣ仕様（図９−５）による、バイパス復号化処理では存在しない。これは本明細書及び特許請求の範囲において、この変数の値を検査することが可能なＣＡＢＡＣ符号化器における現在の手法の実現形態に動機を与えている。
【００２７】
図１は、特定の元の値の有効な別のｍｖｄの後部サフィックス値全てを収集するための実施例を示す。別個の２つのＣＡＢＡＣ符号化エンジンが使用される。主ＣＡＢＡＣ符号化エンジン１００は、後部サフィックス値のＣＡＢＡＣ符号化前後の符号化変数の所要値を集めるために使用される。２次ＣＡＢＡＣ符号化エンジン１２１は、別の後部サフィックス値が使用される場合に符号化処理をシミュレートするために使用される。符号化変数の値を比較することにより、別の後部サフィックス値が有効であるか否かを結論付けることが可能である。
【００２８】
一手法では、まず、符号化前後の符号化変数を保存して、真の後部サフィックスを符号化し、次いで、代替値全ての符号化をシミュレートし、それらの符号化前の変数状態及び符号化後の変数状態を、保存された状態と比較する。少なくとも１つの実施例では、この手法をわずかに修正することが、より単純であることが明らかになった。前部サフィックスを符号化した後、真の後部サフィックスの符号化のシミュレーションが行われ、シミュレートされた符号化の前後に符号化変数が保存されている。代替値全ての符号化のシミュレーションが行われており、それらの符号化前及び符号化後の変数状態の、保存された状態との比較が行われている。これには、標準としての、真の後部サフィックスの符号化が後続している。
【００２９】
図１に具体的に表された手法は、まず、ブロック１０５において前部サフィックスを符号化し、続いて、ブロック１１０において後部サフィックスの符号化前の符号化変数を保存する。続いて、主ＣＡＢＡＣ符号化エンジン１００において、ブロック１１５において元の後部サフィックスが符号化され、続いて、ブロック１２０において元のシンボル値の符号化後の新たな状態を保存する。副ＣＡＢＡＣ符号化エンジン１２１において巡回させるよう、ブロック１２５で表す考えられる後部サフィックス値全てをブロック１３０に供給する一方で、ブロック１１５における後部サフィックスの符号化前の保存された符号化変数を次いで、副ＣＡＢＡＣ符号化エンジン１２１に供給して、ブロック１３０において、後部サフィックスの符号化前のものと等しい符号化変数状態に設定する。次に、ブロック１３５において、符号化変数状態を、後部サフィックスの符号化前のものと等しく設定する。続いて、ブロック１４０において、ブロック１２０からの、元のシンボル値の符号化後の新たな状態を、ブロック１３５における符号化された別の後部サフィックス値と比較する。上記状態が同じ場合、別の後部サフィックス値が保存され、有効とみなされる。
【００３０】
次に、符号化器ベースのＣＢＣにおける変更可能なブロック収集物（ＣＢＣ）アーキテクチャに言及する。ｂｉｔＯｕｔｓｔａｎｄｉｎｇがＣＡＢＡＣ復号化器において利用可能でないという理由で、収集は、ＣＡＢＡＣ符号化処理においてのみ行うことが可能である。図２は、符号化器ベースのＣＢＣシステム・アーキテクチャを示す。ベースバンド・ビデオ画像が利用可能な場合、有効な別の構文値全てを生成するＣＡＢＡＣ符号化器ＣＢＣモジュールに入力される。ブロック２０５における圧縮ビデオ・データのみが利用可能な場合、復号化モジュールは、圧縮ビデオ・データを、ブロック２２０のベースバンド画像に、ブロック２１０において復号化するために使用される。次いで、Ｈ２６４／ＡＶＣ符号化器は、ブロック２３０においてベースバンド画像を符号化し、好ましくはブロック２５０の有効な別の構文値又は構文要素リスト全てを識別するデータ・リストとともにブロック２４０のＨ．２６４／ＡＶＣ圧縮ビットストリームを生成する。
【００３１】
次に、トランスコーダ・ベースの変更可能なブロック収集物（ＣＢＣ）を次いで、図３を参照して記載する。圧縮処理は、計算論的に複雑であり、時間がかかる処理である。専門のオーサリング環境では、圧縮は費用がかかる処理である。ビデオがＨ．２６４／ＡＶＣを使用して既に圧縮されている場合（ブロック３１０に表す）、復号化及びＨ．２６４／ＡＶＣ再圧縮全部は、変更可能なブロック情報を収集するための経済的なやり方でない。図３は、トランスコーダ・ベースの枠組みを示す。ＣＡＢＡＣエントロピ復号化ブロックは、ＣＡＢＡＣエントロピ復号化処理を行うに過ぎず、これは、圧縮ビデオ・データのブロック３２０に表している。復号化構文値は、ブロック３３０のＣＡＢＡＣエントロピ符号化器に転送され、ＣＡＢＡＣエントロピ符号化器は、ブロック３４０の、有効な別の構文値又は構文要素リスト全てを識別するデータ・リストを生成する。
【００３２】
本明細書及び特許請求の範囲記載の実現形態及び構成のうちのいくつかは、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ（ＡＶＣ）標準の意味合いで使用することが可能である。しかし、前述の実現形態及び構成は、別の既存の標準又は将来の標準の意味合いで、又は標準が関係しない意味合いで使用することができる。本発明の用途の具体例を説明してきたが、構成は他の実現形態に対して適合することが可能である。
【００３３】
本明細書及び特許請求の範囲記載の用途は、例えば、方法若しくは処理、装置、ソフトウェア・プログラム、データストリーム、又は信号で実現することができる。単一の形式の実現形態の意味合いでしか記載されていない場合（例えば、方法としてしか記載されていない場合）でも、記載された実現形態又は構成は、他の形式（例えば、装置又はプログラム）で実現することもできる。装置は例えば、適切なハードウェア、ソフトウェア及びファームウェアにおいて実現することができる。上記方法は、例えば、コンピュータや他の処理装置などの装置において更に実現することが可能である。更に、上記方法は、処理装置又は他の装置によって行われる命令によって実現することができ、前述の命令は、集積回路、ＣＤなどのコンピュータ読み取り可能な記憶媒体、若しくは他のコンピュータ読み取り可能な記憶装置に記憶することができる。更に、コンピュータ読み取り可能な媒体は、実現形態によって生成されるデータ値を記憶することが可能である。
【００３４】
当業者に分かるように、実現形態は、例えば、記憶又は伝送することができる情報を搬送するようフォーマッティングされた信号を生成することもできる。情報は例えば、前述の実現形態のうちの１つによって生成されるデータ、又は方法を行うための命令を含み得る。例として、信号は、例えば、透かしを入れたストリーム、透かしを入れていないストリーム、又は、透かしを入れる情報を搬送するようフォーマッティングすることができる。
【００３５】
更に、多くの用途は、符号化器、復号化器、復号化器からの後処理器処理出力、及び符号化器への入力を供給する前処理器のうちの１つ又は複数に適用することが可能である。
【００３６】
除去しようとする可視アーチファクトは、人間の視聴者が見るか、又は気付くことが可能な、表示されたビデオにおける変更であり得ることに留意する。前述のアーチファクトは不快であり得る。更に、許容可能であると認められる変更は、眼でビデオを単に確認することにより、人間の視聴者が検知するか、又は気付くことが可能でないほど微量の特徴（背景の草の方向における変化など）、及び／又は、色、若しくは強度における変化をもたらし得る。
【図１】
0005373909.tif 000006
【図２】
0005373909.tif 000007
【図３】
0005373909.tif 000008