特表2022-526098エントロピコーディングにおいて等確率シンボルをハンドリングするための方法およびデバイス
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-05-23
(54)【発明の名称】エントロピコーディングにおいて等確率シンボルをハンドリングするための方法およびデバイス
(51)【国際特許分類】
H04N 19/91 20140101AFI20220516BHJP
H03M 7/40 20060101ALI20220516BHJP
【ＦＩ】
H04N19/91
H03M7/40
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2021556256
(86)(22)【出願日】2020-03-12
(85)【翻訳文提出日】2021-11-12
(86)【国際出願番号】 EP2020056733
(87)【国際公開番号】W WO2020187709
(87)【国際公開日】2020-09-24
(31)【優先権主張番号】16/356,087
(32)【優先日】2019-03-18
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】500043574
【氏名又は名称】ブラックベリー リミテッド
【氏名又は名称原語表記】ＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２２００ Ｕｎｉｖｅｒｓｉｔｙ Ａｖｅｎｕｅ Ｅａｓｔ， Ｗａｔｅｒｌｏｏ ＯＮ Ｎ２Ｋ ０Ａ７， Ｃａｎａｄａ
(74)【代理人】
【識別番号】100107489
【弁理士】
【氏名又は名称】大塩 竹志
(72)【発明者】
【氏名】フリン， デイビッド
(72)【発明者】
【氏名】ラセール， セバスチャン
【テーマコード（参考）】
5C159
5J064
【Ｆターム（参考）】
5C159MC01
5C159ME11
5C159SS26
5C159UA02
5C159UA05
5J064BA09
5J064BA10
(57)【要約】
データをエンコーディングおよびデコーディングする方法であって、いくつかのデータシンボルは、エントロピコーディングされ、いくつかのデータシンボルは、バイパスコーディングされた。エンコーダが、コーディングされたシンボルをエントロピコーディングされたストリームおよびバイパスコーディングされたストリームに分離する。ストリームは、ストリームの一方を正順で、他方のストリームを逆順で含有するように構造化されたペイロードを有する、データユニット内にパッケージ化され、逆順ストリームは、データユニットの最後と整合される。このように、デコーダでは、デコーダは、正順ストリームのデコーディングをその最初から開始し得、また、シンボルを逆順で抽出することによって、逆順ストリームのデコーディングをデータユニットの最後のその最初から開始し得る。
【特許請求の範囲】
【請求項1】
データユニットをデコーディングし、エンコーディングされたデータを再構築する方法であって、前記方法は、プリアンブルに続いてペイロードを含む前記データユニットを受信することであって、前記ペイロードは、正順ビットストリームに続いて逆順ビットストリームを含む、ことと、
前記データユニットの長さを決定することと、
デコーディングユニットからのシンボルの要求に応答して、正順における前記正順ビットストリームまたは逆順における前記逆順ビットストリームのいずれかからのデータを選択的に読み取ることと、
前記データを前記デコーディングユニット内でデコーディングし、前記シンボルを再構築することと
を含み、
前記正順ビットストリームおよび前記逆順ビットストリームの一方は、エントロピエンコーディングされたシンボルを含み、前記正順ビットストリームおよび前記逆順ビットストリームの他方は、バイパスコーディングされたシンボルを含む、方法。
【請求項2】
前記シンボルの要求は、シンボルタイプが、エントロピコーディングされたか、またはバイパスコーディングされたかを示し、前記正順ビットストリームまたは前記逆順ビットストリームのデータを選択的に読み取ることは、前記シンボルタイプに基づく、請求項１に記載の方法。
【請求項3】
前記方法はさらに、前記プリアンブル後の正ビットストリームの最初の正読取ポインタを初期化することと、前記データユニットの最後の逆読取ポインタを初期化することとを含む、請求項１または２に記載の方法。
【請求項4】
前記正順ビットストリームからのデータを読み取ることは、前記正読取ポインタによって示されるデータを読み取り、次いで、前記正読取ポインタをインクリメントすることを含み、前記逆順ビットストリームからのデータを読み取ることは、前記逆読取ポインタによって示されるデータを読み取り、次いで、前記逆読取ポインタをデクリメントすることを含む、請求項３に記載の方法。
【請求項5】
前記データは、１つ以上のバイトのサイズを有し、前記ポインタをインクリメントおよびデクリメントすることは、前記サイズによるものである、請求項４に記載の方法。
【請求項6】
前記逆順ビットストリームからのデータを逆順において選択的に読み取ることは、前記データユニットのコピーをメモリ内に逆順において記憶することと、逆順データユニットを前記逆順データユニットの最初から開始して正順において読み取ることとを含む、前記請求項のいずれかに記載の方法。
【請求項7】
前記データユニットの長さを決定することは、同期コードワードに基づいて、前記データユニットの最後を検出すること、
長さ値を前記プリアンブルから読み取ること、または
データユニット長をより高いレベルのメタデータから取得すること
のうちの１つを含む、前記請求項のいずれかに記載の方法。
【請求項8】
前記正順ビットストリームおよび前記逆順ビットストリームのデコーディングが完了したことを決定することと、バイト整合のために存在する任意のビットを破棄することとをさらに含む、前記請求項のいずれかに記載の方法。
【請求項9】
前記データユニット内の前記正順ビットストリームと前記逆順ビットストリームとの間に位置付けられる付加的データをデコーディングすることをさらに含む、請求項８に記載の方法。
【請求項10】
エンコーディングされたデータを伝送する方法であって、前記エンコーディングされたデータは、エントロピエンコーディングされたシンボルの第１のビットストリームと、バイパスコーディングされたシンボルの第２のビットストリームとを含み、前記方法は、前記第１のビットストリームおよび前記第２のビットストリームをバッファすることと、
前記第１のビットストリームおよび前記第２のビットストリームの一方を逆転させ、逆順ビットストリームを作成することであって、前記第１のビットストリームおよび前記第２のビットストリームの他方は、正順ビットストリームである、ことと、
プリアンブルに続いて前記正順ビットストリームを含み、その後前記逆順ビットストリームが続くデータユニットを生成することと、
前記データユニットを出力することと
を含む、方法。
【請求項11】
データユニットからエンコーディングされたデータを再構築するためのデコーダであって、前記デコーダは、少なくとも１つのプロセッサと、
メモリと、
プロセッサ実行可能命令を含有するデコーディングアプリケーションであって、前記プロセッサ実行可能命令は、前記少なくとも１つのプロセッサによって実行されると、前記デコーダに、
プリアンブルに続いてペイロードを含む前記データユニットを受信することであって、前記ペイロードは、正順ビットストリームに続いて逆順ビットストリームを含む、ことと、
前記データユニットの長さを決定することと、
デコーディングユニットからのシンボルの要求に応答して、正順における前記正順ビットストリームまたは逆順における前記逆順ビットストリームのいずれかからのデータを選択的に読み取ることと、
前記データを前記デコーディングユニット内でデコーディングし、前記シンボルを再構築することと
を行わせ、
前記正順ビットストリームおよび前記逆順ビットストリームの一方は、エントロピエンコーディングされたシンボルを含み、前記正順ビットストリームおよび前記逆順ビットストリームの他方は、バイパスコーディングされたシンボルを含む、デコーディングアプリケーションと
を備える、デコーダ。
【請求項12】
前記シンボルの要求は、シンボルタイプが、エントロピコーディングされたか、またはバイパスコーディングされたかを示し、前記正順ビットストリームまたは前記逆順ビットストリームのデータを選択的に読み取ることは、前記シンボルタイプに基づく、請求項１１に記載のデコーダ。
【請求項13】
前記プロセッサ実行可能命令は、実行されるとさらに、前記デコーダに、前記プリアンブル後の前記正順ビットストリームの最初の正読取ポインタを初期化させ、前記データユニットの最後の逆読取ポインタを初期化させる、請求項１１または１２に記載のデコーダ。
【請求項14】
前記プロセッサ実行可能命令は、実行されると、前記デコーダに、前記正読取ポインタによって示されるデータを読み取り、次いで、前記正読取ポインタをインクリメントすることによって、前記正順ビットストリームからのデータを読み取らせ、前記プロセッサ実行可能命令は、実行されると、前記デコーダに、前記逆読取ポインタによって示されるデータを読み取り、次いで、前記逆読取ポインタをデクリメントすることによって、前記逆順ビットストリームからのデータを読み取らせる、請求項１３に記載のデコーダ。
【請求項15】
前記データは、１つ以上のバイトのサイズを有し、前記ポインタをインクリメントおよびデクリメントすることは、前記サイズによるものである、請求項１４に記載のデコーダ。
【請求項16】
前記プロセッサ実行可能命令は、実行されると、前記デコーダに、前記データユニットのコピーをメモリ内に逆順において記憶し、逆順データユニットを前記逆順データユニットの最初から開始して正順において読み取ることによって、前記逆順ビットストリームからのデータを逆順において選択的に読み取らせる、請求項１１－１５のいずれかに記載のデコーダ。
【請求項17】
前記プロセッサ実行可能命令は、実行されると、前記デコーダに、同期コードワードに基づいて、前記データユニットの最後を検出すること、
長さ値を前記プリアンブルから読み取ること、または
データユニット長をより高いレベルのメタデータから取得すること
のうちの１つによって、前記データユニットの長さを決定させる、請求項１１－１６のいずれかに記載のデコーダ。
【請求項18】
前記プロセッサ実行可能命令は、実行されるとさらに、前記デコーダに、前記正順ビットストリームおよび前記逆順ビットストリームのデコーディングが完了したことを決定させ、バイト整合のために存在する任意のビットを破棄させる、請求項１１－１７のいずれかに記載のデコーダ。
【請求項19】
前記プロセッサ実行可能命令は、実行されるとさらに、前記デコーダに、前記データユニット内の前記正順ビットストリームと前記逆順ビットストリームとの間に位置付けられる付加的データをデコーディングさせる、請求項１８に記載のデコーダ。
【請求項20】
エンコーディングされたデータを伝送するためのエンコーダであって、前記エンコーディングされたデータは、エントロピエンコーディングされたシンボルの第１のビットストリームと、バイパスコーディングされたシンボルの第２のビットストリームとを含み、前記エンコーダは、少なくとも１つのプロセッサと、
メモリと、
プロセッサ実行可能命令を含有するエンコーディングアプリケーションであって、前記プロセッサ実行可能命令は、前記少なくとも１つのプロセッサによって実行されると、前記エンコーダに、
前記第１のビットストリームおよび前記第２のビットストリームをバッファすることと、
前記第１のビットストリームおよび前記第２のビットストリームの一方を逆転し、逆順ビットストリームを作成することであって、前記第１のビットストリームおよび前記第２のビットストリームの他方は、正順ビットストリームである、ことと、
プリアンブルに続いて前記正順ビットストリームを含み、その後前記逆順ビットストリームが続くデータユニットを生成することと、
前記データユニットを出力することと
を行わせる、エンコーディングアプリケーションと
を備える、エンコーダ。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、概して、データ圧縮に関し、１つの特定の実施例では、シンボルのエントロピコーディングに関する。本願は、エントロピコーディングシステムにおいて等確率シンボルをハンドリングするための方法およびデバイスを説明する。
【背景技術】
【0002】
データ圧縮は、情報を効率的に記憶、伝送、および再現するために、通信およびコンピュータネットワーキングにおいて使用される。データは、概して、アルファベットから描かれるシンボルの形態にある。アルファベットは、いくつかの実施例では、バイナリであり得るが、多くの他の実施例では、非バイナリであり得る。
【0003】
エントロピコーディングは、多くの場合、そうでなければ一連のものまたはシーケンスを表すために要求されるであろうものより少ないビットを要求するように、一連のものまたはシーケンスのシンボルをエンコーディングするために使用される。エントロピコーディングは、ある場合には、コンテキスト適応エントロピコーディングであり得る。例示的エントロピエンコーディングプロセスは、Ｈｕｆｆｍａｎコード、算術コーディング、およびその他等の可変長コードを含む。
【0004】
等確率シンボルから成るアルファベットは、圧縮されることができない。したがって、等確率シンボルを伝達するための算術コーダまたは他の複雑なエントロピコーダを使用するために望ましくない。しかしながら、システム設計の理由から、多くの場合、単一エントロピコーダを使用しながら、通常および等確率シンボルの両方をインターリーブすることが望ましい。
【0005】
エントロピコーディングおよび等確率シンボルの両方を効率的にハンドリングすることが可能である、エンコーダおよびデコーダを提供することが有利であろう。
【発明の概要】
【課題を解決するための手段】
【0006】
本願は、エントロピコーディングされたデータをバイパスコーディングされたデータとともにエンコーディングおよびデコーディングするための方法およびデバイスを説明し、バイパスコーディングされたデータは、等確率シンボルの非エントロピコーディングを含んでもよい。本方法およびデバイスは、個々のストリームの長さをシグナリングする必要性のコストを回避するような様式において、エントロピコーディングおよびバイパスコーディングされたデータのパッケージングストリームをともにペイロード内に含んでもよい。
【0007】
一側面では、本願は、データユニットをデコーディングし、エンコーディングされたデータを再構築する方法を説明する。本方法は、プリアンブルに続いて、ペイロードを含む、データユニットを受信するステップであって、ペイロードは、正順ビットストリームに続いて、逆順ビットストリームを含む、ステップと、データユニットの長さを決定するステップと、デコーディングユニットからのシンボルの要求に応答して、正順における正順ビットストリームまたは逆順における逆順ビットストリームのいずれかからのデータを選択的に読み取るステップと、データをデコーディングユニット内でデコーディングし、シンボルを再構築するステップとを含んでもよい。正順ビットストリームおよび逆順ビットストリームの一方は、エントロピエンコーディングされたシンボルを含み、正順ビットストリームおよび逆順ビットストリームの他方は、バイパスコーディングされたシンボルを含む。
【0008】
別の側面では、本願は、エンコーディングされたデータを伝送する方法を説明し、エンコーディングされたデータは、エントロピエンコーディングされたシンボルの第１のビットストリームと、バイパスコーディングされたシンボルの第２のビットストリームとを含む。本方法は、第１のビットストリームおよび第２のビットストリームをバッファするステップと、第１のビットストリームおよび第２のビットストリームの一方を逆転させ、逆順ビットストリームを作成するステップであって、第１のビットストリームおよび第２のビットストリームの他方は、正順ビットストリームである、ステップと、プリアンブルに続いて、正順ビットストリームを含み、その後、逆順ビットストリームが続く、データユニットを生成するステップと、データユニットを出力するステップとを含んでもよい。
【0009】
さらなる側面では、本願は、そのようなエンコーディングおよびデコーディングする方法を実装するように構成される、エンコーダおよびデコーダを説明する。
【0010】
なおもさらなる側面では、本願は、実行されると、１つ以上のプロセッサに、説明されるエンコーディングおよび／またはデコーディングする方法を実施させる、コンピュータ実行可能プログラム命令を記憶する、非一過性コンピュータ可読媒体を説明する。
【0011】
さらに別の側面では、本願は、コンピュータによって実行されると、コンピュータに、説明されるエンコーディングおよび／またはデコーディングする方法を実施させる、プログラム命令を含有する、コンピュータ可読信号を説明する。
【0012】
本願の他の側面および特徴は、当業者によって、付随の図と併せて、実施例の以下の説明の精査から理解されるであろう。
【図面の簡単な説明】
【0013】
ここで、一例として、本願の例示的実施形態を示す、付随の図面が参照されるであろう。
【0014】
【0015】
【0016】
【0017】
【0018】
【0019】
【0020】
【0021】
【0022】
【0023】
類似参照番号が、類似コンポーネントを示すために異なる図において使用されている場合がある。
【発明を実施するための形態】
【0024】
本発明の一側面または実施形態に関連して説明される任意の特徴はまた、１つ以上の他の側面／実施形態に関して使用されてもよい。本発明のこれらおよび他の側面は、本明細書に説明される実施形態から明白となり、それを参照して解明されるであろう。
【0025】
本願では、用語「および／または」は、列挙された要素単独、任意の副次的組み合わせ、または要素の全てのうちの任意の１つを含め、かつ必ずしも付加的要素を除外せずに、列挙された要素のあらゆる可能性として考えられる組み合わせおよび副次的組み合わせを網羅するように意図される。
【0026】
本願では、語句「…または…のうちの少なくとも１つ」は、列挙された要素単独、任意の副次的組み合わせ、または要素の全てのうちの任意の１つを含め、必ずしも任意の付加的要素を除外せずに、かつ必ずしも要素の全てを要求せずに、列挙された要素のうちの任意の１つ以上のものを網羅するように意図される。
【0027】
最初に、例示的エンコーダ１００のブロック図を示す、図１を参照する。エンコーダ１００は、ソースデータをエンコーディングされたシンボルのビットストリームに変換する、エンコーディングユニット１０２を含む。ソースデータは、圧縮スキームに従って圧縮を受けた任意のデータを含んでもよい。非限定的実施例は、画像データ、オーディオデータ、ビデオデータ、点群データ、および他のタイプのデータを含む。エンコーディングユニット１０２から出力されたビットストリームは、エントロピコーディングを使用してコーディングされたいくつかのシンボルと、バイパスコーディングされているいくつかのシンボルとを含んでもよい。
【0028】
ペイロードパッケージャ１０４は、記憶または伝送のために、ビットストリームを受信し、ビットストリームをパッケージ化する。ある場合には、これは、ビットストリームを部分に分割し、各データユニットが、プリアンブルと、ビットストリームの一部を有するペイロードとを含むように、その部分をパケット化するステップを含む。データユニットは、次いで、記憶または伝送のために出力される。
【0029】
いくつかのインスタンスでは、算術コーダ等のエントロピコーダが、等確率シンボルをハンドリングするように適合されてもよい。例えば、バイナリ算術コーダでは、インターバルの細分割は、簡略化され得る（乗算をビット偏移として実装する等）。しかしながら、依然として、コーデック状態を更新し、デコーディングされたシンボル値を決定する（デコーダにおいて）ために要求される算出が存在する。本最適化は、あるシンボルが静的ｐ＝０．５確率モデルを使用するように指定することによって、圧縮システムの設計において利用され得、指定されたシンボルは、「バイパスコーディングされている」と呼ばれる。Ｈ．２６４｜ＡＶＣおよびＨ．２６５｜ＨＥＶＣビデオ圧縮システムは両方とも、本種類のアプローチを採用する。
【0030】
代替実装では、シンボルストリームは、２つのサブストリームに分裂され得る。第１のストリームは、算術的にコーディングされ、いわゆる算術エントロピコーディングされた（ＡＥＣ）ストリームをもたらす、非バイパスコーディングされたシンボルから成り、第２のストリームは、解凍されたバイパスコーディングされたシンボルのシーケンスである。２つの別個のストリームをパッケージ化および伝送するために、長さフィールドが、第１のコーディングされたサブストリームの長さＬを示すために使用され、これは、次いで、デコーダが、同時に、両方のストリームにアクセスすることを可能にし、これは、デコーディングの間、シンボルを適切なシーケンスにおいて再多重化することが可能であるために行われる必要がある。本アプローチは、長さフィールドの付加的シグナリングに起因して、また、デコーダが第２のサブストリームの最初（位置Ｌ＋１における）にアクセスするために、Ｌの長さの第１のサブストリームの全体をバッファすることを要求することから、減少された圧縮効率をもたらす。
【0031】
一側面では、本願は、長さフィールドのシグナリングオーバーヘッドを伴わずに、エントロピコーディングストリームおよびバイパス－コーディングされたストリームの並行デコーディングを有効にする、シンボルをコーディングする方法を提供する。コーディングされたデータが、デコーダによって決定可能な長さを有する、データユニット内でシグナリングされる、システムでは、データユニットのペイロードは、ストリームの一方を正順において、他方のストリームを逆順において含有するように構造化され、逆順ストリームは、データユニットの最後と整合される。このように、デコーダでは、デコーダは、プリアンブルまたは他のメタデータ構造に続いて、正順ストリームをデータユニットの正面の近くのその最初からデコーディングすることを開始し得、また、シンボルを逆順で抽出することによって、逆順ストリームをデータユニットの最後のその最初からデコーディングすることを開始し得る。着目すべきこととして、デコーダは、それらのデコーディングを開始するために、ストリームのいずれかの長さを把握する必要はない。さらに、デコーダでは、それを両端から消費することが可能であるために、データユニット全体をメモリ内にバッファする必要があろうことを理解されたい。
【0032】
一実施例では、逆順ポインタが、データユニットの最後から開始し、コーディングされたシンボルが逆順ストリームから読み取られるにつれて、デクリメントされてもよい。別の実施例では、データユニットは、メモリに逆順においてコピーされ、逆ストリームポインタは、逆転されたデータユニットの最初と整合され、次いで、逆順ストリームのコーディングされたシンボルを順序通り読み取るようにインクリメントされてもよい。
【0033】
図２は、例示的データユニット２００を図式的に図示する。データユニット２００は、プリアンブル２０２をその最初に含むように構造化される。プリアンブル２０２は、ヘッダ情報を含有し、これは、種々の実施形態では、例えば、バージョンコード、種々のタイプのシグナリングフラグ（例えば、デコーディングまたは再構築プロセスによって使用されるべきパラメータ）、タイムスタンプ、データタイプコード等のメタデータを含んでもよい。プリアンブルは、プロトコルによって固定される長さを有してもよい、ビットストリーム内のいずれかの場所でシグナリングされる固定長を有してもよい、または最後のコードまたは同等物の検出を通して等、デコーダによって決定可能な可変長を有してもよいことを理解されたい。いくつかの実装では、プリアンブル２０２は、データユニット長をシグナリングしてもよい。これは、明示的長さフィールドを含んでもよい、または長さは、データユニットタイプコードまたは長さ値にリンクされる他のメタデータを用いて規定されてもよい。
【0034】
伝送順序においてプリアンブル２０２に続くものは、ペイロード２０４である。ペイロード２０４のフロントエンドは、正順ストリーム２０６を含有する。正順ストリーム２０６は、ペイロード２０４の最初と整合される。ペイロード２０４はさらに、逆順ストリーム２０８を含む。逆順ストリーム２０８は、逆転に先立ったビットストリームのオリジナルの最初がデータユニット２００の最後と整合するように、逆転され、ペイロード２０４に追加されている、ビットストリームである。
【0035】
一実施例では、正順ストリーム２０６は、エントロピコーディングされたシンボルを含有し、逆順ストリーム２０８は、バイパスコーディングされたシンボルを含有する。別の実施例では、正順ストリーム２０６は、バイパスコーディングされたシンボルを含有し、逆順ストリーム２０８は、エントロピコーディングされたシンボルを含有する。
【0036】
デコーダでは、プリアンブル２０２を読み取り後、デコーダは、２つのポインタ、すなわち、正順ストリーム２０６の最初に初期化される、正読取ポインタと、データユニット２００の最後、すなわち、逆順ストリーム２０８の最初に初期化される、逆読取ポインタとを初期化してもよい。当業者によって、データユニットの最後の逆読取ポインタを初期化する概念は、データのバイト、ワード、または他のユニットの最初の位置に初期化され、その最後は、次いで、データユニット２００の最後と整合し、必ずしも、ポインタがデータユニット２００の最後のビットをポインティングするわけではないことを意味し得ることが理解されるであろう。
【0037】
シンボルが、データのデコーディングおよび再構築のために要求されるため、デコーダは、要求されるシンボルタイプに応じて、正順ストリーム２０６または逆順ストリーム２０８のいずれかからコーディングされたシンボルを読み取る。シンボルが、逆順ストリーム２０８から読み取られるにつれて、逆読取ポインタは、デクリメントされる。
【0038】
逆順ビットストリーム２０８は、オリジナルビットストリームのビット毎逆転を通して生成されてもよいことを理解されたい。ある場合には、逆順ビットストリーム２０８は、特に、メモリがバイト単位でアドレス指定される場合、オリジナルビットストリームのバイト毎逆転を通して生成されてもよい。同様に、正読取ポインタのインクリメントまたは逆読取ポインタのデクリメントは、各シンボル読取動作を用いて抽出されたコーディングされたデータのサイズに応じて、ポインティングされているメモリ場所のビット毎変化、ポインティングされているメモリ場所のバイト毎変化等に対応し得る。ワード、ハーフワード、またはその他を含む、他の粒度もまた、使用されてもよい。
【0039】
上記に説明される技法を使用することで、ストリームの長さは、デコーダがデータユニット２００の長さを把握または決定し得ることを前提として、デコーダにシグナリングされる必要はない。一実施例では、データユニットの長さは、プロトコルスタック内のより高いレベルにおいて事前に規定される。実施例は、ネットワークデータグラムペイロード長、ファイルフォーマット、アプリケーションプログラミングインターフェース（ＡＰＩ）定義、または他の高レベル仕様を含む。別の実施例では、プリアンブル２０２自体が、データユニットの長さを示す信号を含有するように構造化される。長さは、例えば、プリアンブル２０２内に明示的に規定されてもよい。代替として、コードまたは他のインデックスが、例えば、具体的データユニット長と関連付けられる、データユニットタイプを示してもよい。さらに別の実施例では、プリアンブル２０２は、データユニットの最初をデコーダにシグナリングする、同期コードワードを含んでもよい。伝送されるビットストリーム内の次の同期コードワードを見出すことによって、デコーダは、データユニット２００の長さを決定することが可能である。
【0040】
ここで、ブロック図形態において、一例示的エンコーダ３００を図示する、図３を参照する。エンコーダ３００は、２つのストリーム、すなわち、エントロピコーディングされたストリーム３０４と、バイパスコーディングされたストリーム３０６とを生成する、エンコーディングユニット３０２を含む。いくつかの実施例では、エンコーディングユニット３０２は、その中にエントロピコーディングおよびバイパスコーディングされたデータがインターリーブされる、単一ビットストリームを生成する。そのような実施形態では、エンコーディングユニット３０２はさらに、デマルチプレクサを含み、シンボルタイプに基づいて、ストリームを２つのストリーム３０４、３０６に分離する。
【0041】
本明細書で使用されるような用語「シンボルタイプ」は、シンボルがエントロピコーディングまたはバイパスコーディングされているかどうかを指す。シンボルタイプは、あるシンボルのためのあるコーディング機構を定める、コンテキストモデルによって規定されてもよい。例えば、変換ドメイン係数のビデオコーディングの例示的場合では、コンテキストモデルは、重要度係数フラグ、１超フラグ、および同等物をエントロピコーディングするためのコンテキストを決定するためのあるコンテキスト決定動作を定め得る。さらに、例えば、符号ビット等のあるシンボルは、バイパスコーディングされるべきである、すなわち、そのようなシンボルの確率は、ｐ＝０．５に静的に設定されることを規定してもよい。いくつかの実施例では、下記にさらに説明されるであろうように、コンテキスト適応システムにおいてエントロピエンコーディングされるように指定されるシンボルは、期せずして、それらが、エントロピコーディングされるのではなく、バイパスコーダに再ルーティングされる、等確率（ｐ＝０．５）に十分に近い、確率を有し得る。
【0042】
エンコーダ３００はさらに、バッファ３０８を含み、エントロピコーディングされたストリーム３０４およびバイパスコーディングされたストリーム３０６を記憶する。バッファ３０８は、１つ以上の物理的メモリおよび／または物理的メモリの一部を含んでもよい。
【0043】
バッファ３０８は、いくつかの実施形態では、ストリーム３０４、３０６の一方を逆順において記憶してもよい。すなわち、記憶動作は、データ順序の逆転をストリーム３０４、３０６の一方に適用するステップを含んでもよい。上記に述べられたように、逆転は、ビット毎、バイト毎、またはある他のレベルであってもよい。
【0044】
エンコーダ３００はさらに、ペイロードパッケージャ３１０を含む。ペイロードパッケージャ３１０は、選択された伝送プロトコルに従った伝送のために、データをパケット化およびパッケージ化するように構成される、データ伝送ユニットの一部であってもよい。ペイロードパッケージャ３１０は、パッケージ化されたデータをデータユニット３１２の形態において出力する。データユニット３１２は、図２に説明されるように構造化される。すなわち、プリアンブルから開始し、その後、正順ストリームが続き、逆順ストリームで終了する。本実施例では、正順ストリームは、エントロピコーディングされたストリーム３０４を含んでもよく、逆順ストリームは、バイパスコーディングされたストリーム３０６の逆コピーを含んでもよい。
【0045】
バッファ３０８が、バイパスコーディングされたストリーム３０６を逆順において記憶するように構成される場合、逆順ストリームは、逆記憶されたバイパスコーディングされたストリーム３０６をバッファ３０８から読み取ることによって、ペイロードパッケージャ３１０によって取得されてもよい。バッファ３０８が、バイパスコーディングされたストリーム３０６をその正コーディング順序で記憶する場合、ペイロードパッケージャ３１０は、それをデータユニット３１２の中に挿入する前に、バイパスコーディングされたストリーム３０６を逆転してもよい。一実施例では、これは、バイパスコーディングされたストリーム３０６をバッファ３０８から逆順において読み取るステップを含んでもよい。
【0046】
また、逆順ストリームは、データユニット３１２の最後と整合されるべきであることを理解されたい。データユニット３１２が、事前に規定されたまたは固定長である場合、ペイロードパッケージャ３１０は、バッファビットおよび／またはバイトを追加し、バイパスコーディングされたストリーム３０６の最初のバイト（コーディング順序において）がデータユニット３１２の最後のバイト位置にあることを確実にしてもよい。データユニットが、事前に規定された長さではない場合、ペイロードパッケージャ３１０は、ビットをエントロピコーディングされたストリーム３０４およびバイパスコーディングされたストリーム３０６の最後（コーディング順序において）に追加し、処理がバイト毎である場合、それらがバイト整合されることを確実にするように構成されてもよい。それらのパディングビットは、ストリーム３０４および３０６のデコーディングが完了されたことを決定すると、デコーダによって破棄されてもよい。デコーダは、デコーディングプロセスの動作を通して、使用されているコンテキスト適応デコーディングプロセスに従って、シンボルを消費し、したがって、コーディングのセクションの最後（例えば、再構成されているデータのコーディングスキーム事前規定部分）に到達したときを決定し得ることを理解されたい。
【0047】
バッファ３０８は、ある場合には、１つを上回るバッファ／メモリを含んでもよい。２つのストリームの長さは、概して、それらがエンコーディングユニット３０２によって生成されるため、事前に把握されないため、２つのバッファのいずれかは、後続連結動作とともに使用される、または単一の十分に大きいバッファが、使用され、連結は、バッファ内のデータを移動させることによって実施される。例えば、バイパスコーディングされたストリームは、エントロピコーディングされたストリームの最後と整合するように移動されてもよい。代替として、プリアンブルおよび正エントロピコーディングされたストリームは、逆転されたバイパスコーディングされたストリームの最初と整合するように移動されてもよい。
【0048】
いくつかの実装では、ペイロードパッケージャ３１０は、それに対してデータを書き込み、データユニット３１２を組み立てる、その独自の出力バッファを有してもよい。いくつかの実装では、ペイロードパッケージャ３１０は、例えば、上記に議論される連結／逆転動作を使用して、バッファ３０８を使用して、データユニット３１２を組み立てる。
【0049】
ここで、ブロック図形態において、例示的デコーダ３００を示す、図４を参照する。デコーダ４００は、上記の説明に従って構造化された１つ以上のデータユニットを受信する。デコーダ４００は、データユニットを受信する、ペイロードデパッケージャ４０２を含む。ペイロードデパッケージャ４０２は、ある場合には、伝送プロトコルに応じて、データユニットを他のカプセル化から抽出してもよい。ペイロードデパッケージャ４０２は、データユニットまたは少なくともペイロードをバッファ４０４内に記憶してもよい。ある場合には、ペイロードデパッケージャ４０２は、データユニットのコピーをバッファ４０４に正（伝送）順序で書き込む。一実施例では、ペイロードデパッケージャ４０２は、第２のデータユニットのコピーをバッファ４０４に書き込むが、逆記憶されたデータユニットの最初がペイロードの最後と整合される（逆）バイパスコーディングされたストリームの最初であるように、それを逆順において書き込む（ビット毎、バイト毎、または別様に）。
【0050】
本実施例では、ペイロードデパッケージャ４０２は、データユニットの単一コピーをバッファ４０４に書き込むことが想定される。上記に記載されるように、データユニットは、プリアンブル４０６と、正順ストリーム４０８と、逆順ストリーム４１０とを含む。
【0051】
デコーダ４００は、いくつかの実施例では、正順ストリーム４０８の最初のビット／バイトにおける正読取ポインタ４１２を初期化してもよく、逆順ストリーム４１０の最初のビット／バイト／等における逆読取ポインタ４１４を初期化してもよい。デコーディングユニット４１６は、当該データのためのコーディングモデルに従って、デコーディングおよび再構築プロセスを管理する。デコーディングプロセスが進むにつれて、デコーディングユニット４１６は、デコーディングプロセスおよび使用されているコンテキストモデルに基づいて、次のコーディングされたシンボルを要求４１８する。要求４１８は、シンボルタイプ、すなわち、エントロピコーディングされているかまたはバイパスコーディングされているかを示してもよい。読取動作が、次いで、要求４１８内のシンボルタイプに応じて、正順ストリーム４０８または逆順ストリーム４１０のいずれかからの記憶されたデータユニットから、データの一部、例えば、コーディングされたシンボルを読み取るために生じる。読取動作は、要求されるシンボルタイプに応じて、正読取ポインタ４１２または逆読取ポインタ４１４によって示されるアドレスから、コーディングされたシンボルを抽出する。正読取ポインタ４１２または逆読取ポインタ４１４は、それぞれ、次いで、インクリメントまたはデクリメントされる。
【0052】
エントロピコーディングされたストリームが、算術的にエンコーディングされたビットストリーム、すなわち、ＡＥＣストリームである、実施例では、ＡＥＣデコーダは、ビットストリームからのビットの一部が、離散シンボルに対応しないが、代わりに、ビットストリームのビットのある部分が、コンテキスト確率に基づいて、ビンのシーケンスのコーディングを反映させる、連続インターバルの算術コーディングを定義するという点で、幾分、非同期して起動することを理解されたい。その意味で、ＡＥＣデコーダは、一連の算術的にエンコーディングされたビン（シンボル）をデコーディングする際、ビットストリームからビットのシーケンスを消費し得、これは、次いで、シンボルの要求４１８に応答して、デコーディングユニット４１６に利用可能にされる。そのような実施形態では、ポインタの「インクリメント」は、ＡＥＣデコーダによってデコーディングされたシンボルの出力ではなく、ＡＥＣデコーダによるビットストリームのビットの消費に結び付けられる。
【0053】
一例示的エンコーディングプロセス５００を図示する、フローチャートが、図５に示される。エンコーディングプロセス５００は、エントロピコーディングされたストリームおよびバイパスコーディングされたストリームが生成されおり、適用可能である場合、統合されたストリームから逆多重化されると想定する。プロセス５００は、動作５０２において、生成されるにつれて、エントロピコーディングされたストリームおよびバイパスコーディングされたストリームの少なくとも一部をバッファするステップから開始する。バイパスコーディングされたストリームは、本実施例では、動作５０４において逆転される。上記に述べられたように、ある場合には、本逆転は、動作５０２において、バイパスコーディングされたストリームをバッファ内に記憶するときに生じ得る。ある場合には、本逆転は、記憶後に生じ得る。ある場合には、逆転動作５０４は、バイパスコーディングされたストリームを読み取り、バッファに逆順において再度書き込むことによって生じる。ある場合には、逆転動作５０４は、バイパスコーディングされたストリームをバッファから逆順において読み取ることによってペイロードを生成するときに生じる。
【0054】
動作５０６では、エンコーダが、プリアンブルに続いて、正順ストリームを伴い、その後に、逆順バイパスコーディングされたストリームが続く、データユニットを生成する。コーディング順序において、バイパスコーディングされたストリームの最初は、データユニットの最後と整合される。
【0055】
データユニットは、次いで、動作５０８において、出力される。
【0056】
例示的デコーディングプロセス６００が、図６におけるフローチャートの方法によって図示される。デコーディングプロセス６００は、動作６０２において、上記に議論される構造を有する、データユニットを受信するステップを含む。すなわち、データユニットは、プリアンブルと、ペイロードとを含む。ペイロードは、エントロピコーディングされたストリームと、バイパスコーディングされたストリームとを含む。ストリームの一方は、正順において、プリアンブルの直後にデータユニット内に現れ、他方のストリームは、逆順において、データユニットの最後と整合される。ビットパディングまたは他のデータ等のデータが、ペイロード内の２つのストリーム間にある場合とそうではない場合がある。本実施例の目的のために、バイパスコーディングされたストリームは、逆順ストリームであることが想定される。
【0057】
デコーダは、動作６０４において、データユニットの長さを決定する。上記に述べられたように、データユニットの長さは、伝送タイプ、コーディングプロトコル、より高いレベルヘッダ情報、またはある他の外部ソースよって事前に規定されてもよい。ある場合には、データユニットの長さは、明示的または暗示的に、プリアンブル内で規定されてもよい。ある場合には、データユニットの長さは、デコーダが、データの着信ビットストリーム内の次の同期コードワードを見出すことによって、データユニットの長さを決定するように、各プリアンブル内の同期コードワードを用いて、シグナリングされてもよい。
【0058】
データユニットは、デコーダ内のメモリ内に記憶される。動作６０６において、デコーダは、エントロピコーディングされたストリームの最初における第１の読取ポインタを初期化し、コーディング順序の意味において、バイパスコーディングされたストリームの最初、すなわち、データユニットの最後における第２の読取ポインタを初期化する。動作６０８において、コーディングされたシンボルの要求が、生成される。要求は、デコーディングおよびデータ再構築プロセスの一部として、シンボルをデータユニットからデコーディングおよび再構築する、デコーディングプロセスによって駆動される。例示的プロセスは、オーディオコーディング、ビデオコーディング、マルチメディアコーディング、点群コーディング、または他のデータ圧縮プロセスを含む。
【0059】
要求と関連付けられるシンボルタイプが、動作６１０において決定される。すなわち、要求は、バイパスコーディングされたシンボルまたはエントロピコーディングされたシンボルのいずれかに関するものである。要求されるシンボルが、バイパスコーディングされている場合、動作６１２において、データは、正順ストリーム、すなわち、第１の読取ポインタによってポインティングされているエントロピコーディングされたストリームのその部分から読み取られる。第１の読取ポインタは、次いで、動作６１４において、インクリメントされる。逆に言えば、要求されるシンボルが、バイパスコーディングされている場合、動作６１６において、データは、逆順ストリーム、すなわち、第２の読取ポインタによってポインティングされているエントロピコーディングされたストリームのその部分から読み取られる。第２の読取ポインタは、次いで、動作６１８において、デクリメントされる。デコーダは、場合によって、抽出されたコーディングされたシンボルをエントロピデコーダまたはバイパスデコーダにパスする。
【0060】
いくつかの実施形態では、デコーダは、第２のデータユニットのコピーをメモリ内に逆順において記憶してもよいことを理解されたい。その場合、第２の読取ポインタは、逆順データユニットの最初における点に初期化され、第２の読取ポインタは、バイパスコーディングされたシンボルが読み取られるにつれて、インクリメントされる。
【0061】
動作６２０において、デコーダは、バイパスコーディングされたストリームおよびエントロピエンコーディングされたストリームのデコーディングが終了したかどうかを評価する。該当しない場合、動作６０８に戻り、次のシンボル要求を評価する。該当する場合次いで、動作６０２において、次のデータユニットに移動する。
【0062】
ストリームの一方の全体をデコーディングせずに、ストリームの最後を決定することは、不可能であることを理解されたい。故に、エントロピデコーダ、例えば、算術デコーダの動作は、後続ビットをストリームから破棄するために、境界されたビットストリーム読取に依拠しない。境界された読取動作は、事前に定義された数のビットを読み取った後、事前に定義された一定値を返すものである。換言すると、エントロピエンコーディングされたストリームは、自己完結型でなければならない。
【0063】
上記に議論されるように、バイト毎アドレス指定は、多くのシステムにおいて共通であって、これは、コーディングされたストリームの一方のバイト毎逆転を含む、コーディングされたデータのバイト毎ハンドリングにつながり得る。８つのバイパスシンボルの各抽出後、ポインタ参照解除を回避するために、いくつかのシステムは、現在のサブストリームバイトを中間変数にコピーし得る。マルチバイト中間変数を使用して、効率を増加させることは、逆転されたバイパスサブストリームの各バイトの構成ビットの適切なビット順序付けによって促進されることができる。
【0064】
リトルエンディアンデータモデルを使用する、アーキテクチャの場合、マルチバイト動作を有効にするために、各バイト内のビットは、所与のバイト内の最大有効ビットが、そのバイト内でアンパックされるべき最初のビットであって、所与のバイト内の最小有効ビットが、そのバイト内でアンパックされるべき最後のビットであるように、順序付けられてもよい。ビットａ…ｘ（ビットａは、デコーディングされるべき最初のビットであって、ｘは、最後である）のシーケンスに関して、結果として生じるサブストリーム構造は、以下のように図示され得る。
【表1】
【0065】
リトルエンディアンアーキテクチャ上では、アドレスＮ－３における３バイトワードの読取は、バイナリワードａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｂをもたらす。本性質は、任意の機械ワードサイズに拡張可能である。変数Ｌが、現在のワードの現在のビットレベル読取（または書込）位置を追跡するために使用されてもよい。
【0066】
単一ビットＶをＱビットサイズワードＷから抽出するための１つの方法は、ＷのＭＳＢを次の未読ビットとして維持することである。
【化1】
【0067】
ここで、別の例示的データユニット７００の構造を図式的に示す、図７を参照する。本実施例では、上記に説明されるように、データユニット７００は、プリアンブル７０２と、ペイロード７０４とを含み、ペイロード７０４は、正順ストリーム７０６と、逆順ストリーム７０８とを含む。しかしながら、正順ストリーム７０６と逆順ストリーム７０８との間において、ペイロード７０４は、付加的データ７１０を含む。有利なこととして、デコーダが２つのストリーム７０６および７０８をデコーディングするにつれて、その個別の長さを発見し、次いで、それらの間に記憶されるデータ７１０を抽出することが可能である。
【0068】
一実施例は、付加的データ７１０のために、非デコーディングされたスタッフィングデータを使用する。データユニットが、所与の構文または文法に従って解析されると、付加的データを解釈するための試行は、行われない。エンコーダは、本性質を利用して、フラッシング動作（潜在的に、必要より多くのデータをフラッシングする）を簡略化する、または付加的データ７１０を使用して、ビットストリームを識別するために使用され得る、隠蔽されたマーカを挿入する、または代替として、スタッフィングデータを使用して、最小ビットレート要件を満たしてもよい。
【0069】
別の例示的実装では、付加的データ７１０は、実質的であってもよい。一実施例では、ストリーム７０６、７０８をデコーディング後、デコーダ状態を形成する、２つのビットストリームポインタが、隣接するバイトをポインティングしない場合、付加的データ７１０が、存在し、デコーダによって解析される。付加的データ７１０は、正または逆順のいずれかで伝達されてもよい。順序の正確な選択肢は、周囲ストリーム７０６、７０８の予期される使用に依存し得る。例えば、１つのストリームが、他より前に終了することが把握されている場合、そのストリームの順序が、使用されてもよい。ある構造では、順序は、逆順がデコーダのためにより効率的ストリームアクセスを提供するかどうかに依存し得る。
【0070】
付加的データ７１０は、エントロピコーディングされたデータ、バイパスコーディングされたデータ、または他のデータであってもよい。一実施例では、データ７１０は、データユニット７００が、再帰的にネスト化された対のエントロピコーディングおよびバイパスコーディングされたストリーム対を含有するように、別の対の正順および逆順ビットストリームである。付加的データ７１０は、さらなるプリアンブルを含む場合とそうではない場合がある。
【0071】
存在するとき、付加的データ７１０を解析するために、一実施形態では、デコーダ読取ポインタは、前進され、フラッシングまたはバイト整合の目的のために、個別のストリームの中に挿入される任意のビットをスキップし、任意の部分的ビットをデコーダバッファから効果的に破棄する。代替実施形態は、最初の対応するストリームのフラッシングまたはバイト整合を省き、代わりに、後続ストリームのバイト整合およびフラッシングを要求してもよい（但し、後続ＡＥＣストリームの再初期化は、それでもなお、生じる必要があり得る）。そのようなシステムでは、エンコーダは、付加的データ７１０がデータユニット７００内に含有されるべきではない場合、ストリームをフラッシングまたはバイト整合させるであろう。
【0072】
プリアンブルは、付加的データ７１０がビットストリーム内に存在するかどうかをシグナリングする、フラグを含有してもよい。いくつかの実装では、フラグは、ビットストリーム構造に関する形式的制限を示し、任意のスタッフィングデータの不在を確実にしてもよい。例えば、データユニット内の全ての解析可能データが解析された後、デコーダは、デコーダ状態を形成する、２つのビットストリームポインタが、隣接するバイトをポインティングすることを確認する。フラグが、付加的データ７１０が存在することを示すためにビットストリーム内（例えば、プリアンブル内）で先にシグナリングしない限り、２つのビットストリーム点は、隣接するバイトをポインティングしなければならない、または誤差が、検出される。
【0073】
上記の実施例の多くでは、エントロピコーダは、コーディングモデルによって事前規定されたシンボルタイプに基づいて、エントロピコーディングされたストリームおよびバイパスコーディングされたストリームを生成した。すなわち、コーディングプロセスは、おそらく、シンボルタイプに起因して、特定のシンボルが、コンテキスト適応的にエントロピコーディングされるべきかどうか、またはシンボルが、ｐ＝０．５の静的確率を有し、全ての場合においてバイパスコーディングされるべきかどうかを示す。しかしながら、いくつかのコンテキスト適応コーディングプロセスでは、コンテキストが、下層データの統計に応じて、関連付けられた確率がｐ＝０．５に接近するように進化することが生じ得る。そのような場合、それらがコンテキストモデルに従ってエントロピコーディングされることになっているという事実にもかかわらず、エントロピコーダを使用するのではなく、そのようなシンボルをバイパスコーダに仕向けることが有益であり得る。
【0074】
関連付けられる適応確率モデルを用いたシンボルに関して、例示的プロセスは、以下を含み得る。
【0075】
現在のシンボル確率ｐｒｏｂ０が、点検され、それと等確率（例えば、バイナリシンボルに関しては０．５）との間の差異が、閾値に対して試験される。例示的閾値は、例えば、０．０５未満または０．０３未満であってもよい。
【0076】
差異が、閾値未満である場合、シンボルは、通常のバイパスシンボルとして処理される。そうでなければ、算術コーデック等のエントロピコーダによって処理される。両方の場合において、シンボル確率モデル（すなわち、ｐｒｏｂ０の次の値）は、シンボル値、現在のシンボル確率、およびコンテキスト適応コーディングスキーム内で通常の更新関数に従って更新される。
【0077】
ここで、エンコーダ８００の例示的実施形態の簡略化されたブロック図を示す、図８を参照する。エンコーダ８００は、プロセッサ８０２と、メモリ８０４と、エンコーディングアプリケーション８０６とを含む。エンコーディングアプリケーション８０６は、メモリ８０４内に記憶され、実行されると、プロセッサ８０２に、本明細書に説明されるもの等の動作を実施させる、命令を含有する、コンピュータプログラムまたはアプリケーションを含んでもよい。例えば、エンコーディングアプリケーション８０６は、本明細書に説明されるプロセスに従って、データユニットをエンコーディングおよび出力してもよい。エンコーディングアプリケーション８０６は、コンパクトディスク、フラッシュメモリデバイス、ランダムアクセスメモリ、ハードドライブ等の非一過性コンピュータ可読媒体上に記憶されてもよいことを理解されたい。命令が、実行されると、プロセッサ８０２は、説明されるプロセスを実装する、特殊目的プロセッサとして動作するように、命令内に規定された動作および機能を行う。そのようなプロセッサは、いくつかの実施例では、「プロセッサ回路」または「プロセッサ回路網」と称され得る。
【0078】
ここでまた、デコーダ９００の例示的実施形態の簡略化されたブロック図を示す、図９を参照する。デコーダ９００は、プロセッサ９０２と、メモリ９０４と、デコーディングアプリケーション９０６とを含む。デコーディングアプリケーション９０６は、メモリ９０４内に記憶され、実行されると、プロセッサ９０２に、本明細書に説明されるもの等の動作を実施させる、命令を含有する、コンピュータプログラムまたはアプリケーションを含んでもよい。デコーディングアプリケーション９０６は、コンパクトディスク、フラッシュメモリデバイス、ランダムアクセスメモリ、ハードドライブ等のコンピュータ可読媒体上に記憶されてもよいことを理解されたい。命令が、実行されると、プロセッサ９０２は、説明されるプロセスを実装する、特殊目的プロセッサとして動作するように、命令内に規定された動作および機能を行う。そのようなプロセッサは、いくつかの実施例では、「プロセッサ回路」または「プロセッサ回路網」と称され得る。
【0079】
本願によるデコーダおよび／またはエンコーダは、限定ではないが、サーバ、好適にプログラムされた汎用コンピュータ、マシンビジョンシステム、およびモバイルデバイスを含む、いくつかのコンピューティングデバイス内に実装されてもよいことを理解されたい。デコーダまたはエンコーダは、本明細書に説明される機能を行うようにプロセッサまたは複数のプロセッサを構成するための命令を含有する、ソフトウェアを用いて実装されてもよい。ソフトウェア命令は、ＣＤ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を含む、任意の好適な非一過性コンピュータ可読メモリ上に記憶されてもよい。
【0080】
本明細書に説明されるデコーダおよび／またはエンコーダ、およびエンコーダまたはデコーダを構成するための説明される方法／プロセスを実装する、モジュール、ルーチン、プロセス、スレッド、または他のソフトウェアコンポーネントは、標準的コンピュータプログラミング技法および言語を使用して実現されてもよいことを理解されたい。本願は、特定のプロセッサ、コンピュータ言語、コンピュータプログラミング慣例、データ構造、他のそのような実装詳細に限定されない。当業者は、説明されるプロセスは、揮発性または不揮発性メモリ内に記憶されるコンピュータ実行可能コードの一部として、特定用途向け集積チップ（ＡＳＩＣ）の一部として等で実装されてもよいことを認識するであろう。
【0081】
本願また、本願に従ったエンコーディングプロセスのアプリケーションを通して生産されたデータをエンコーディングする、コンピュータ可読信号を提供する。
【0082】
説明される実施形態のある適合および修正が、行われることができる。したがって、上記の議論される実施形態は、制限的ではなく、例証的であると見なされる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】