(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-23
(45)【発行日】2023-08-31
(54)【発明の名称】符号化されたビデオビットストリームの低遅延消費
(51)【国際特許分類】
H04N 19/423 20140101AFI20230824BHJP
H04N 19/152 20140101ALI20230824BHJP
H04N 19/46 20140101ALI20230824BHJP
H04N 19/593 20140101ALI20230824BHJP
【ＦＩ】
H04N19/423
H04N19/152
H04N19/46
H04N19/593
【請求項の数】
20
(21)【出願番号】P 2020560303
(86)(22)【出願日】2019-02-26
(65)【公表番号】
(43)【公表日】2021-08-30
(86)【国際出願番号】 IB2019051542
(87)【国際公開番号】W WO2019207368
(87)【国際公開日】2019-10-31
【審査請求日】2022-02-24
(31)【優先権主張番号】15/965,281
(32)【優先日】2018-04-27
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】508301087
【氏名又は名称】エーティーアイ・テクノロジーズ・ユーエルシー
【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ
【住所又は居所原語表記】Ｏｎｅ Ｃｏｍｍｅｒｃｅ Ｖａｌｌｅｙ Ｄｒｉｖｅ Ｅａｓｔ， Ｍａｒｋｈａｍ， Ｏｎｔａｒｉｏ， Ｌ３Ｔ ７Ｘ６ Ｃａｎａｄａ
(74)【代理人】
【識別番号】100108833
【弁理士】
【氏名又は名称】早川 裕司
(74)【代理人】
【識別番号】100111615
【弁理士】
【氏名又は名称】佐野 良太
(74)【代理人】
【識別番号】100162156
【弁理士】
【氏名又は名称】村雨 圭介
(72)【発明者】
【氏名】アフメド エム． アブデルカレク
(72)【発明者】
【氏名】エドワード エイ． ハロルド
(72)【発明者】
【氏名】アンディ サン
(72)【発明者】
【氏名】スティーヴン ホー
(72)【発明者】
【氏名】レイ ジャン
(72)【発明者】
【氏名】イハブ アメール
(72)【発明者】
【氏名】ガボール シネス
(72)【発明者】
【氏名】ジキ ハオ
(72)【発明者】
【氏名】ヤン リウ
(72)【発明者】
【氏名】バオチュン リ
(72)【発明者】
【氏名】カイ サン
【審査官】田中 純一
(56)【参考文献】
【文献】国際公開第２０１８／０７４２９１（ＷＯ，Ａ１）
【文献】特表２０１７－５３５１６７（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０１００１９６（ＵＳ，Ａ１）
【文献】特開２０１７－２２５１５２（ＪＰ，Ａ）
【文献】特開２０１５－０６２３２４（ＪＰ，Ａ）
【文献】米国特許第０５７６８５３３（ＵＳ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ７／１２
Ｈ０４Ｎ １９／００ － １９／９８
ＩＥＥＥ Ｘｐｌｏｒｅ
(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】
【図1】コンピューティングシステムの一実施態様のブロック図である。
【図2】エンコーダ及びビットストリームコンシューマに関する動作の一実施態様のタイミング図である。
【図3】エンコーダ及びビットストリームコンシューマに関する動作の別の実施態様のタイミング図である。
【図4】コンピューティングシステムの別の実施態様のブロック図である。
【図5】コンシューマモジュールに結合されるビデオエンコーダの一実施態様のブロック図である。
【図6】所与のビデオフレームが符号化されている間に所与のビデオフレームの符号化されたビデオビットストリームへのオンザフライアクセスを可能にするための方法の一実施態様を示す全体的フロー図である。
【図7】ビットストリームが符号化されているときに、リアルタイムで符号化されたビデオビットストリームにアクセスするコンシューマモジュールに関する方法の一実施態様を示す全体的フロー図である。
【図8】ビットストリーム書き込みポインタ更新の粒度を制御するための方法の一実施態様を示す全体的フロー図である。
【図9】消費されているチャンクにわたる予測を行うビデオエンコーダに関する方法の一実施態様を示す全体的フロー図である。
【図10】符号化されたビデオビットストリームのチャンクのリアルタイム消費の一実施態様のタイミング図を示す。
【発明を実施するための形態】
【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】
前述の実施態様は、単なる実施態様の非限定的な例にすぎないことを強調したい。いったん上記の開示が十分に理解されると、多くの変形及び修正が当業者に明らかになる。以下の「特許請求の範囲」は、全ての係る変形及び修正を包含すると解釈されることが意図される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】