JP6026443B2 - ビデオ・ビットストリーム中の描画方向情報 - Google Patents

Description

関連出願の記載
本出願は、発明の名称を「ビデオ・ビットストリームにおける描画方向情報」とした、２０１１年３月１０日出願の米国仮特許出願番号６１／４５１，３０３の優先権を主張し、その開示内容は引用により全体として本明細書に取り込む。

本願は、ビデオ符号化に関し、より具体的には、ビデオ・ビットストリーム内部の再構築されたビデオ・ビットストリームの空間的方向に関する情報の表現に関する。

特定のビデオ符号化標準は、ビデオ会議およびデジタルＴＶ環境のコンテキストで考案されたものであり、キャプチャされたまたは再構築されたビデオ信号の空間解像度および方向は、キャプチャ／エンコーダおよびデコーダ／ディスプレイの場所で同一である可能性がある。例えば、ＴＶ信号は、風景フォーマットで４：３または１６：９のアスペクト比でキャプチャすることができ、やはり風景フォーマットで描画される（しかし、受信側のＴＶではアスペクト比をユーザの嗜好に基づいて調整してもよい）。偶然にも、ＩＴＵ−ＴのＲｅｃ．Ｈ．２６１、Ｈ．２６２、Ｈ．２６３、Ｈ．２６４（これらは全て、Ｐｌａｃｅ ｄｅ Ｎａｔｉｏｎｓ、ＣＨ−１２１１ Ｇｅｎｅｖａ ２０、ＳｗｉｔｚｅｒｌａｎｄにあるＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）、または、ｗｗｗ．ｉｔｕ．ｉｎｔで入手可能）、ならびに、ＭＰＥＧ−１ビジュアル（正式にはＩＳＯ／ＩＥＣ１１１７２−２として知られている）、およびＭＰＥＧ−４ビジュアル（正式にはＩＳＯ／ＩＥＣ１４４９６−２として知られている）（１、ｃｈ．ｄｅ ｌａ Ｖｏｉｅ−Ｃｒｅｕｓｅ、Ｃａｓｅ ｐｏｓｔａｌｅ ５６、ＣＨ−１２１１ Ｇｅｎｅｖａ ２０、ＳｗｉｔｚｅｒｌａｎｄにあるＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）または、ｗｗｗ．ｉｓｏ．ｏｒｇで入手可能）（これらは全て、引用により全体として本明細書に取り込む）を含む、特定のビデオ圧縮標準には、キャプチャされたビデオ信号の空間的方向に関する情報が含まれていない。

コンピュータ・ベースのデコーダ／描画装置に接続されたスクリーンの利用により、それらがＰＣ（Ｐｅｒｓｏｎａｌ コンピュータ）、セット・トップ・ボックス、携帯電話およびタブレット・コンピュータのようなモバイル装置、または他の任意の同様な装置であろうと、ビデオ・イメージを当該装置の固有の方向でない方向に、例えば当該イメージをスクリーンの「ウィンドウ」に置くことにより描画することができる。上述の装置の一部では、本質的にそれらがハンドヘルドであるという形態的な要因のため、または技術的手段（スイベル・モニタ）により、２方向以上での視聴が可能である。オペレーティング・システムおよびＧＵＩでは、再構築されたビデオ信号の「固有の」方向には無関心かもしれない。

上述したことは、概念的には、キャプチャ側にも同様に当てはまる。今日、ＴＶおよびビデオ会議の視覚信号は風景モードでキャプチャすることができるが（大部分がそうである）、カメラをそのキャプチャ軸回りに回転し、それにより別の方向でキャプチャすることを行わない技術的な理由はない。それを行うには、自然な視聴体験を可能とするために描画装置が再構築画像を回転する必要がありうる。

ビデオ・ビットストリームにおいて、（再構築後に）描画すべきビデオ・ビットストリームの方向の指示を可能とする機構がなければ、描画装置は描画方向に関して十分な情報を得たうえでの決定を行うことができず、これが悪いユーザ体験につながりうる。

さらに、制作中にカメラを回転させるのは、映画プロデューサの芸術表現に関する選択肢である。忠実な視聴体験のためには、ビデオ内容がシーケンス中に変化しうるので当該回転をビデオ内容と同期する必要がある。これにより、所望の機能を提供できない、拡張ＪＦＩＦ標準（１、ｃｈ．ｄｅ ｌａ Ｖｏｉｅ−Ｃｒｅｕｓｅ、Ｃａｓｅ ｐｏｓｔａｌｅ ５６、ＣＨ−１２１１ Ｇｅｎｅｖａ ２０、ＳｗｉｔｚｅｒｌａｎｄにあるＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）または、ｗｗｗ．ｉｓｏ．ｏｒｇで入手可能であり引用により本明細書に取り込まれる、ＩＳＯ／ＩＥＣ１０９１８−５ドラフト）で知られるもののような、ファイル・フォーマット・ベースの方向情報が生成される。カメラ方向をビデオ内容と有意義に同期するためには、方向情報がビデオ・ビットストリームにおいて利用可能である必要がある。

したがって、ビデオ・ビットストリームにおいて、再構築すべきビットストリームの方向の信号送信を可能とする機構を設けることが望ましい。

開示した発明特定事項では、ビデオ・ビットストリーム内部において、再構築後のビットストリームから生ずるビデオ信号の方向を示す副次的情報を提供する。

１態様では、ビデオ・ビットストリーム内の１ビットにより、「人物」モードおよび「風景」モードの何れかを示す。

同一または別の態様では、ビデオ・ビットストリーム内の２ビットにより、風景モードからの０／９０／１８０／２７０度の偏差を示す。同一または別の態様では、ビデオ・ビットストリーム内の２ビットにより、人物モードからの０／９０／１８０／２７０度の偏差を示す。

同一または別の態様では、ビデオ・ビットストリーム内の２ビットにより、最後の既知のカメラ位置からの０／９０／１８０／２７０度の偏差を示す。

同一または別の態様では、ビデオ・ビットストリーム内の２ビットにより、重力軸からの０／９０／１８０／２７０度の偏差を示す。図７Ａ、７Ｂ、７Ｃ、７Ｄは、重力軸（７０１）に関して０、９０、１８０、および２７０度の位置にあるカメラを示す。図７Ｂでは、重力軸（７０１）はまた、カメラの自然な方向である。

同一または別の態様では、適切なエントロピ符号化の枠組みに従って符号化されビットストリーム内に配置された整数または浮動小数点により、風景、人物からの方向変化の程度、最後の既知のカメラ位置からの方向変化の程度、または重力軸からの方向変化の程度を示す。

同一または別の態様では、ビデオ・ビットストリーム内の２ビット（または、適切なエントロピ符号化の枠組みに従って符号化されビットストリームに配置された整数または浮動小数点）により、カメラの自然な方向または不特定の方向からの０／９０／１８０／２７０度（または、整数もしくは浮動小数点により示される別の角度）の偏差を示す。

同一または別の態様では、１ビットで左右反転を示す。

同一または別の態様では、１ビットで上下反転を示す。

同一または別の態様では、持続性情報が、整数値または浮動小数点値として符号化され、時間、フレーム間隔、または画像順序カウント間隔（ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ ｉｎｔｅｒｖａｌ）のうち何れか１つで測定した回転情報の持続性を示す。

同一または別の態様では、上述のビットまたはエントロピ符号化された数値の何れかが、ビデオ・ビットストリーム内の補助強化情報メッセージで符号化される。

同一または別の態様では、上述のビットまたはエントロピ符号化された数値の何れかが、パラメータ集合の視覚的使用性情報（ＶＵＩ）部分で符号化される。当該パラメータ集合を、ビデオ・ビットストリーム内に配置することができ、または、帯域外で運搬することができる。

開示した発明特定事項のさらなる特徴、性質、および様々な利点は、下記の発明を実施するための形態および添付図面からより明らかになる。

本発明の１実施形態に従うシステムの概略図である。 キャプチャされ描画されたシーンの概略図である。 本発明の１実施形態に従うビデオ・ビットストリームの概略図である。 本発明の１実施形態に従う方向情報の例示的な表現の概略図である。 本発明の１実施形態に従う人物モードおよび風景モードで符号化されたキャプチャされたシーンの概略図である。 本発明の諸実施形態に従うコンピュータ・システムの概略図である。 重力軸に関して配向されたカメラの概略図である。

図面は、本開示に取り込まれ、その一部を構成する。図面全体にわたって、同一の参照番号および文字は、特に明記しない限り、図示した実施形態の同様な特徴、要素、構成要素または部分を示すために用いる。さらに、開示した発明特定事項を、図面を参照して詳細に説明するが、その説明は例示的な実施形態に関連して行う。

図１は、開示した発明特定事項の適用例として、ビデオ会議システムの関係する部分を示す。カメラ（１０１）はシーンをキャプチャする。当該カメラは、手動で、または、電動カメラ・ヘッド（１０３）により、そのキャプチャ軸（１０２）の回りに回転することができる（カメラ・ヘッドは、任意であるため、点線で示してある）。（図示したように）カメラ（１０１）内、カメラ・ヘッド（１０３）内、または別の適切な場所に配置したセンサ（１０４）を使用してカメラ（１０１）のキャプチャ方向を特定することができる。あるいは、カメラ回転のオープン・ループ（センサなし）制御が実装されるときは、カメラ・ヘッドが直接に方向を与えることもできる。例えば、操作者が手動でカメラを水平（風景）方向に設定し、カメラ・ヘッドがステッピング・モータを用いてカメラを回転することが可能である。ここで、各ステップは例えば１度の回転に相当する。モータに送信されたステッパ・パルスを計測することで、カメラ・ヘッドはセンサなしにカメラの方向を「知る」。カメラが固定位置にあることも同様に可能である。ここで、風景位置以外の任意の位置（画像の水平走査線に垂直な重力軸）で、開示された技術が利用されている。

上記カメラ（１０１）にはビデオエンコーダ（１０５）が接続されている。ビデオエンコーダ（１０５）は方向決定モジュール（１０６）を備えることができる。方向決定モジュール（１０６）はセンサ（１０４）、またはカメラ・ヘッド（１０３）もしくは他の任意の適切な装置からその入力（１０７）を受け取ることができ、または、方向決定モジュール（１０６）は、例えばシーンの水平線、シーン内の人の方向、落下物が示す重力の方向等を観察することにより、当該方向をビデオ内容から導くことができる。方向決定モジュールに方向符号化モジュール（１０８）を接続することができる。方向符号化モジュール（１０８）は、方向決定モジュール（１０６）により決定される方向をビデオ・ビットストリーム内の適切な位置にエンコードすることができる。これを行うために、方向符号化モジュール（１０８）はエンコーダ（１０４）内のビットストリーム生成（１０９）の残部と対話して、例えば、ビットストリーム内の方向指示ビットの正しい位置を決定することができる。方向情報を１つまたは複数のビットとして表現できる例については後述する。本明細書で説明した様々なモジュールは、ハードウェアおよびソフトウェアの任意の適切な組合せを含むことができる。

上記エンコーダ（１０５）の出力は、符号化されたビデオ・ビットストリーム（１１０）であり、当該ビデオ・ビットストリーム（１１０）は、一定の中間ステップ（例えば、ファイル・フォーマットへの組込み、パケット化、例えばネットワークを介しての配信、逆パケット化等）の後、デコーダ（１１１）に到達することができる。

上記デコーダ（１１１）において、方向デコード・モジュール（１１２）は方向情報を表現するビットをビットストリームから抽出することができる。方向デコード・モジュール外でのデコード・プロセスの残部は通常通りに処理され、結果は、一般に風景モードにおける一連のキャプチャされた解像度のイメージである。

上記方向デコード・モジュール（１１２）は、例えば方向情報エンコードの逆プロセスに従うことによって、ビットストリーム内の方向情報をデコードすることができる。結果の情報を、例えば、デコードされた画素の行列を必ずしも風景方向にはないウィンドウ内に正確に配置できる（場合によってはソフトウェア・ベースの）描画器（１１３）が利用できるようにすることができる。別の使用形態は、方向変換をＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）（１１４）により実施させることであり、これは、メインＣＰＵの処理割当量の観点から有利であり、または、描画器がＧＰＵ可能な携帯電話で実行されているといった特定のシナリオでの電力節約の観点から有利でありうる。ＧＰＵ（１１４）で方向情報を利用可能とする別の利点は、ＧＰＵ（１１４）が、色空間変換またはリサイズのような作業を実施するために、符号化されたビデオ・ビットストリームの再構築画像の画素でとにかく動作しなければならないかもしれないことである。このケースでは、ＧＰＵ（１１４）は、幾つかの実装形態において、どのような大量のサイクルまたはメモリ・アクセスをも発生させることなく方向を変更することができ、これにより、バッテリの寿命やＣＰＵサイクルの節約が支援される。さらに別の利用形態には、カメラ・ヘッド（１０２）と同様に、（スイベル・スクリーンとしても知られる）物理的に回転可能なスクリーン上で描画することがある。さらに別の形態を、ここでより詳細に検討する。描画装置（１１６）はタブレットＰＣまたは携帯電話であってもよく、これらは、重力軸（１１８）に対するスクリーン（１１５）の位置を決定するための内部センサ（１１７）を有することができる。どのようにユーザが自分の装置を保持するかに応じて、装置（１１６）のスクリーン（１１５）は、例えば風景モードまたは人物モードにある。図示した装置（１１６）は人物モードでのスクリーン（１１５）を示し、これは、図示した例示的な装置に対しては「自然な」方向である。下記で説明するように、描画装置の内部センサ（１１７）と方向情報が、ビデオ・ビットストリーム（１１０）内で利用可能であり方向デコーダ（１１２）によりデコードされ、カメラ（１０１）または描画装置（１１６）の方向に関わらずユーザが常に（方向の視点から）視覚的に好ましい再構築画像を受け取ることを保証することができる。

図２は、人物モードおよび風景モードのみに着目した、キャプチャ方向および描画方向の４つの異なる構成を示す。

第１のシーンでは、カメラ（２０１）は風景モードでキャプチャし、表示方向（２０２）も風景モードである。カメラ（２０１）およびディスプレイ（２０２）の方向は同一であり、画像を、開示した技術を使用してまたは使用せずに適切に描画することができる。

第２のシーンでは、カメラ（２０３）は人物モードでキャプチャするために時計回りに９０度回転している。提示した開示した発明特定事項を使用しないと、（利用可能な最大画面サイズに拡大した後の）描画結果はディスプレイ（２０４）に示すように見えるはずである。具体的には、画像は９０度回転したように見え、人が利用するには有用でない。

シーン３では、カメラ（２０５）は再び９０度回転しているが、開示した発明特定事項に従う方向情報はビットストリーム内に提示されている。ビットストリームデコーダは、キャプチャ方向が回転していることを知らなくともよい。しかし、既に説明したように、方向デコーダは、ビットストリームを描画すべき方向を当該ビットストリームから決定している。方向デコーダは描画情報を描画器に転送することができる。描画器はこの情報を使用して、再構築イメージを回転し（かつ、必要に応じて拡大し）、再構築イメージを視聴者に対して好ましいようにディスプレイ（２０６）上に提示してもよい。

シーン４では、カメラ（２０７）およびスクリーン（２０８）の両方が９０度回転している。開示した発明特定事項がなく、描画装置が方向センサを有さないときは、再構築画像は正しく描画されるはずである。しかし、ますます、ハンドヘルド装置は方向センサを備えており、ユーザ・インタフェースは再構築されたビデオを含みうるスクリーン内容を回転し、その結果、上のディスプレイ（２０６）で示したものと同様に、視覚的に好ましくない回転イメージが描画されることとなる。しかし、方向情報がビットストリーム内で利用可能であるときは、方向デコーダはこの情報をデコードし描画器に転送することができ、描画器は画像を視覚的に好ましい方向に表示することができる（２０８）。

直接再構築画像を「真っ直ぐに」描画することにより視覚的に好ましい結果を実現することは、視聴者の視点からは、開示した発明特定事項の１つの応用例にすぎない。次に、別の例示的な使用を説明する。一部のビデオ内容に対しては、画像をもとの方向とは異なる方向で（例えば、風景モードではなく人物モードで）符号化することが符号化効率に関して有利でありうることが分かっている。正方形でない画像に対しては、この方向の変更により画像のサイズが変化する。これは、多くの最近のビデオ符号化標準がサポートできるものである。図５を参照すると、４：３の風景フォーマット（５０１）でのシーンが示されている。エンコーダは、マクロブロック（５０２）に対する通常のラスタ走査順を用いて、このシーンを（方向変換のない）キャプチャされたものとして処理することができる。各正方形は大きさが４ｘ３であるマクロブロックの画像のうちの１つのマクロブロックを示し、図示した整数値は走査順を表す。しかし、１実施形態によれば、エンコーダは処理前にイメージを、ここでは例えば時計回りに９０度だけ、回転することができる。本例では、画像の大きさは３ｘ４のマクロブロックに変化している。この人物イメージおよび風景イメージの両方を、通常の符号化手段および示したマクロブロックの走査順を用いて、符号化することができる。マクロブロック間予測（ｃｒｏｓｓ−ｍａｃｒｏｂｌｏｃｋ ｐｒｅｄｉｃｔｉｏｎ）の特性は方向を変更すると変化する可能性があり、結果の回転画像を符号化するのに必要なビット数も変化する可能性がある。エンコーダは、例えば、２つ、３つ、またはそれより多くの様々な回転（例えば、０、９０、１８０、および２７０度の回転）をテストして、最小数のビットを利用する符号化イメージを選択することができる。これらのビットおよび回転情報により、デコーダはイメージを適切な方向に再構築することができる。これは、視覚的体験に対して重要であるだけでなく、画像間予測を使用するときに参照するための再構築画像を使用するのにも重要である。

図３を参照し、引用により本明細書に取り込まれるＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６４を用いると、例えば、方向情報（３０１）を（標準的な構文および意味を適切に修正した後）ビットストリームの様々な部分に配置することができる。１つの位置は、視覚的使用性情報（ＶＵＩ）データ構造（３０２）であることができ、これは、シーケンス・パラメータ集合（ＳＰＳ）（３０３）のオプションの部分である。視覚的使用性情報は、現在標準化されており、描画器が再構築イメージを適切に描画するのを支援する画素アスペクト比または色空間情報のようなフィールドを含む。方向情報はこのカテゴリに適合する。パラメータ集合に方向情報を含めることには、情報が紛失し易くないという利点がある。情報の紛失は、ＳＥＩメッセージには容易に起こりうることである（下記を参照）。

Ｈ．２６４ビットストリームの別の適切な部分は、標準化されたまたはベンダ固有の補助強化情報（ＳＥＩ）メッセージ（３０５）に存在するはずである。ＳＥＩメッセージを、ビデオ・シーケンス内部において、スライス（３０４）または画像境界に配置することができる。ＳＥＩメッセージを利用することには、（Ｈ．２６４で定義される）ビデオ・シーケンス内部で、または、シーケンス・パラメータ集合を変更することなく単一のシーケンスを超えて、様々な方向情報を信号送信できるという利点がある。これは、カメラの方向がシーケンスの中で変化する可能性があり方向情報をビデオのビットと同期して送信すべきときに、望ましい。しかし、ＳＥＩメッセージが確実に運搬されるとは想定されず、その結果、方向情報が紛失する可能性があり、上述したようにビデオ内容が視覚的に好ましくないように描画する結果となりうる。

前述の選択肢は、相互に排他的なものではなく、幾つかのシナリオでは、ＳＥＩメッセージがパラメータ集合に存在する情報を上書きすることにより、双方を同時に使用するための合理的な設計上の選択事項でありうる。

ビデオ符号化のビットストリームのフォーマットに応じて、ＧＯＰまたは画像ヘッダ、スライスヘッダ、画像パラメータ集合等のような、ビットストリーム内の他の場所も同様に適切でありうる。Ｈ．２６４標準（およびそれに類するもの）ベースの実装に対しては、符号化の効率をサポートするのに適した方向情報の位置は、例えば画像パラメータ集合のような、デコード・プロセスに必要なビットストリームの部分でありうる。このケースでは、ＳＥＩメッセージまたはＶＵＩの使用は得策ではない。なぜならば、デコードの後に参照画像を生成するためには、デコーダが画像ごとに、方向を変更する必要があるかどうかを知る必要があるからである。

図４を参照すると、方向情報をビットストリームにおいて様々なフォーマットで表現することができる。そのうち幾つかを以下で説明する。当該フォーマットは、とりわけ、その方向を示す粒度と、方向をビットストリームで符号化するのに必要な結果のビット数とにおいて、相違する。

１つのフォーマットを、「風景」モードまたは「人物」モード（４０２）を示す単一のビット（４０１）で符号化することができる。風景に対するＴＶ信号の従来の優先度が与えられると、「人物」は時計回り９０度のカメラ回転を示すことができる。上の図２と関連して上述した利用シナリオに対しては、この情報は述べた機能を提供するのに既に十分である。

別のフォーマットは２ビット（４０３）から成り、例えば反時計回りに０、９０、１８０、２７０度（４０４）の回転を示す。この情報を、重力軸に対して、過去に受け取った方向情報に対して、または別のコンテキストで、推論することができる。この情報を、標準化する（したがって、方向情報がビットストリーム内に見つかるとき暗黙的に仮定される）か、または、明示的に信号送信することができる。例えば、ビット（４０５）は、（０に設定されるとき）「重力軸に対して絶対的」または（１に設定されるとき）「以前の方向に対して相対的」と示すことができる。漸進的な情報符号化は、方向の動的な変化が期待されるときに最も適切であり、方向情報はＳＥＩメッセージで符号化される。

より細かい粒度の回転角度も可能である。例えば、９ビットの整数（４０７）を使用して、（９ビットの数字が提供する５１２個の値空間のうち３６０個の値を用いて）０度から３５９度の間の回転を１度の粒度で示すことができる。

同様に、浮動小数点を使用することができる。

幾つかの応用例では、鏡面イメージを正確に描画するために、画像の左右または上下への反転を信号送信することが得策でありうる。

上述した回転の表現の全ては、幾つかの環境では、回転情報の持続性、および／または、デコーダが回転情報のリフレッシュまたは更新を受け取ることを期待できる周波数を示す情報から利益を享受することができる。これは、ＳＥＩメッセージのＮＡＬユニット・ヘッダ内のｎａｌ＿ｒｅｆ＿ｉｄｃフィールドが示すように、ＳＥＩメッセージの転送優先度が破棄可能なＮＡＬユニットであることを示す０である必要があるためＳＥＩメッセージが紛失する可能性が高いことを考慮すれば、特に有用でありうる。例えば持続性情報で指定される間隔のタイムアウトを通じて回転情報を含むＳＥＩメッセージが紛失した可能性を認識するに至ったデコーダは、例えば回転が変化しなかったと仮定することによって、過去の回転変化の統計的頻度分析に基づいて適切に対応することができる。持続性情報を任意の適切なエントロピ符号化フォーマット（即ち、整数、浮動小数点、ＣＡＢＡＣ符号化した整数）で表現することができ、例えば時間（ミリ秒）、フレーム間隔、または画像順序カウント間隔で測定することができる。

上述の情報の全てを、直接ビットストリームに配置することができ、または、使用中のビデオ圧縮技術のエントロピ符号化枠組みを用いてエントロピ符号化することができる。例えば、Ｈ．２６４のコンテキストでは、値を二値符号化するか、または、ＣＡ−ＶＬＣ、またはＣＡＢＡＣのエントロピ符号化機構に従って暗号化することができる。

開示した発明特定事項によれば、本明細書に記載の回転情報符号化技術をハードウェアおよびソフトウェアの任意の適切な組合せを用いて実装できること理解される。前述の速度推定および制御技術を実装し操作するためのソフトウェア（即ち、命令）をコンピュータ読取可能媒体で提供することができる。当該コンピュータ読取可能媒体は、限定ではなく、ファームウェア、メモリ、記憶装置、マイクロコントローラ、マイクロプロセッサ、集積回路、ＡＳＩＣ、オンラインでダウンロード可能な媒体、および他の利用可能な媒体を含むことができる。

コンピュータ・システム
上述のビデオ符号化の方法を、コンピュータ読取可能命令を用いてコンピュータ・ソフトウェアとして実装することができ、コンピュータ読取可能媒体に物理的に格納することができる。コンピュータ・ソフトウェアを任意の適切なコンピュータ言語を用いてエンコードすることができる。ソフトウェア命令を様々な種類のコンピュータで実行することができる。例えば、図６は、本開示の諸実施形態を実装するのに適したコンピュータ・システム６００を示す。

図６に示すコンピュータ・システム６００の構成要素は本質的に例示的なものであって、本開示の諸実施形態を実装するコンピュータ・ソフトウェアの使用範囲または機能範囲に関して何ら限定を示唆しようとするものではない。また、諸構成要素の構成が、コンピュータ・システムの例示的な実施形態で示した構成要素のどの１つまたは組合せに関してどのような依存性または要件も有するとは解釈すべきでない。コンピュータ・システム６００は、多くの物理的な形態を有することができる。当該形態には、集積回路、プリント基板、（携帯電話またはＰＤＡのような）小型ハンドヘルド装置、パーソナル・コンピュータ、またはスーパー・コンピュータが含まれる。

上記コンピュータ・システム６００は、ディスプレイ６３２、１つまたは複数の入力装置６３３（例えば、キーパッド、キーボード、マウス、スタイラス・ペン等）、１つまたは複数の出力装置６３４（例えば、スピーカ）、１つまたは複数の記憶装置６３５、様々な種類の記憶媒体６３６を備える。

システム・バス６４０は多種多様なサブシステムを接続する。当業者が理解するように、「バス」とは共通の機能を果たす複数のデジタル信号線をいう。システム・バス６４０は数種のバス構造のうち任意のものであることができる。当該バス構造には、メモリ・バス、周辺バス、および様々なバス・アーキテクチャを用いたローカル・バスが含まれる。限定ではなく例として、かかるアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＶＬＢ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ ｌｏｃａｌ）バス、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス、ＰＣＩ−Ｘ（ＰＣＩ−Ｅｘｐｒｅｓｓ）バス、およびＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バスが含まれる。

プロセッサ（複数可）６０１（中央演算装置またはＣＰＵとも呼ばれる）は、場合によっては、命令、データ、またはコンピュータ・アドレスを一時的に局所的に記憶するためのキャッシュ・メモリ・ユニット６０２を含む。プロセッサ（複数可）６０１は、メモリ６０３を含む記憶装置に接続される。メモリ６０３は、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）６０４およびＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）６０５を含む。当業界で公知なように、ＲＯＭ６０５はデータおよび命令を単方向でプロセッサ（複数可）６０１に転送するように動作し、ＲＡＭ６０４は一般にデータおよび命令を双方向に転送するように使用される。これらの種類のメモリは両方とも、後述するコンピュータ読取可能媒体のうち任意の適切なものを含むことができる。

固定記憶部６０８はまた、場合によっては記憶制御ユニット６０７を介して、プロセッサ（複数可）６０１に双方向的に接続される。固定記憶部６０８は追加のデータ記憶容量を提供し、後述するコンピュータ読取可能媒体のうち何れかを備えることもできる。記憶部６０８を使用してオペレーティング・システム６０９、ＥＸＥＣ６１０、アプリケーション・プログラム６１２、データ６１１等を格納することができる。記憶部６０８は、一般には、主記憶より低速な（ハード・ディスクのような）二次記憶媒体である。記憶部６０８内部に保持された情報は、適切な場合は、メモリ６０３内の仮想メモリとして標準的な形で取り込むことができることは理解されよう。

上記プロセッサ（複数可）６０１はまた、グラフィック制御６２１、ビデオ・インタフェース６２２、入力インタフェース６２３、出力インタフェース６２４、記憶インタフェース６２５のような様々なインタフェースに接続され、これらのインタフェースは適切な装置に接続される。一般に、入出力装置は、ビデオ・ディスプレイ、トラック・ボール、マウス、キーボード、マイクロフォン、タッチ・センシティブ・ディスプレイ、トランスデューサ・カード・リーダ（ｔｒａｎｓｄｕｃｅｒ ｃａｒｄ ｒｅａｄｅｒ）、磁気テープ・リーダもしくは紙テープ・リーダ、タブレット、スタイラス・ペン、音声認識器もしくは手書き認識器、生体認証装置、または他のコンピュータのうち何れかであることができる。ネットワーク・インタフェース６２０を用いて、プロセッサ（複数可）６０１を別のコンピュータまたは通信ネットワーク６３０に接続することができる。かかるネットワーク・インタフェース６２０により、ＣＰＵ６１０が、上述の方法を実施する過程で情報をネットワーク６３０から受け取り、または、情報を当該ネットワークに出力できることが考慮されている。さらに、本開示の方法の実施形態を、ＣＰＵ６０１で単独で実施することができ、または、インターネットのようなネットワーク６３０を介して、処理の一部を共有するリモートＣＰＵ６０１と協働して実行することができる。

様々な実施形態によれば、ネットワーク環境において、即ち、コンピュータ・システム６００がネットワーク６３０に接続されているとき、コンピュータ・システム６００は、やはりネットワーク６３０に接続されている他の装置と通信することができる。ネットワーク・インタフェース６２０を介して、通信をコンピュータ・システム６００に対して送受信することができる。例えば、別の装置からの要求または応答のような、１つまたは複数のパケットの形で入ってくる通信を、ネットワーク・インタフェース６２０でネットワーク６３０から受信することができ、メモリ６０３内の選択されたセクションに格納して処理することができる。別の装置への要求または応答のような、１つまたは複数のパケットの形で出ていく通信も、メモリ６０３の選択されたセクションに格納することができ、ネットワーク・インタフェース６２０でネットワーク６３０に送出することができる。プロセッサ（複数可）６０１は、処理用にメモリ６０３に格納したこれらの通信パケットにアクセスすることができる。

さらに、本開示の諸実施形態は、様々なコンピュータ実行型の動作を実施するためのコンピュータ・コードを格納したコンピュータ読取可能媒体を有するコンピュータ記憶製品に関する。当該媒体およびコンピュータ・コードは、本開示の目的に特に設計され構築されたものであることができ、または、コンピュータ・ソフトウェア業界の当業者に公知であり利用可能であるものであることができる。コンピュータ読取可能媒体の例には、ハード・ディスク、フロッピ・ディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭおよびホログラフィック装置のような光媒体、光ディスクのような光磁気媒体、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、ＰＬＤ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）ならびにＲＯＭおよびＲＡＭ装置のような、プログラム・コードを格納し実行するように特に構成されたハードウェア装置が含まれるがこれらに限らない。コンピュータ・コードの例には、コンパイラが生成したもののような機械コード、インタプリタを用いてコンピュータにより実行される高レベルなコードを含むファイル、が含まれる。本明細書で開示した発明特定事項に関連して使用される「コンピュータ読取可能媒体」という用語は送信媒体、搬送波、または他の一時的信号を包含しないことは当業者には理解される。

限定ではなく例として、アーキテクチャ６００を有するコンピュータ・システムは、プロセッサ（複数可）６０１がメモリ６０３のような１つまたは複数の有形のコンピュータ読取可能媒体で具体化されたソフトウェアを実行した結果としての機能を提供することができる。本開示の様々な実施形態を実装するソフトウェアをメモリ６０３に格納してプロセッサ（複数可）６０１により実行することができる。コンピュータ読取可能媒体は、具体的なニーズに従って、１つまたは複数のメモリ装置を含むことができる。メモリ６０３はソフトウェアを、大容量記憶装置（複数可）６３５のような１つまたは複数の他のコンピュータ読取可能媒体から、または、通信インタフェースを介して１つまたは複数の他のソースから、読み取ることができる。当該ソフトウェアにより、プロセッサ（複数可）６０１に本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。当該プロセスには、メモリ６０３に格納されたデータ構造を定義すること、当該ソフトウェアにより定義されたプロセスに従ってかかるデータ構造を修正することが含まれる。追加または代替として、コンピュータ・システムは、ロジックを回路においてハードワイヤードしまたはそうでなければ具体化した結果としての機能を提供することができる。当該ロジックは、ソフトウェアの代わりにまたはソフトウェアとともに、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行するように動作させることができる。必要に応じて、ソフトウェアへの言及がロジックを包含することができ、逆も成り立つ。必要に応じて、コンピュータ読取可能媒体への言及が、実行用のソフトウェアを格納する（ＩＣ（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）のような）回路、実行用のロジックを具体化する回路、またはその両方を包含することができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組合せを包含する。

本開示では幾つかの例示的な実施形態を説明したが、変更、並び、および様々な代替的な均等物が存在し、これらは本開示の範囲内にある。したがって、本明細書では明示的には図示または説明しなかったが、本開示の原理を具体化し従って本開示の趣旨および範囲内にある多数のシステムおよび方法を当業者が考案できることは理解される。

１０１ カメラ
１０２ キャプチャ軸
１０３ カメラ・ヘッド
１０５ ビデオエンコーダ
１１６ 描画装置

Claims (9)

1. 少なくとも１つの入力画像の方向をエンコーダで決定するステップと、
   方向情報を符号化されたビデオのビットストリームに含まれる補助強化情報（ＳＥＩ）メッセージでエンコードするステップと、
   を含み、
   前記方向情報は前記入力画像の全ての画素についての上下反転を示す単一のビットを含み、前記方向情報の持続性に関する持続性情報がフレーム数または画像順序カウント間隔のうち少なくとも１つを含む、
   ビデオエンコードの方法。
2. 符号化されたビデオのビットストリームに含まれる補助強化情報（ＳＥＩ）メッセージから方向情報を取り出すステップと、
   前記符号化されたビデオのビットストリームをデコードして、一連の画像を生成するステップと、
   を含み、
   前記方向情報は前記一連の画像のうち少なくとも１つの画像の全ての画素についての上下反転を示す単一のビットを含み、前記方向情報の持続性に関する持続性情報がフレーム数または画像順序カウント間隔のうち少なくとも１つを含む、
   ビデオデコードの方法。
3. 前記方向情報を使用して少なくとも１つの再構築ビデオ画像を描画するステップをさらに含む、請求項２に記載の方法。
4. 方向情報を決定するように構成された方向決定モジュールと、
   前記方向決定モジュールに接続され、前記方向決定モジュールにより決定された前記方向情報をエンコードするように構成された方向符号化モジュールと、
   前記方向符号化モジュールに接続され、方向情報を含む少なくとも１つの補助強化情報（ＳＥＩ）メッセージを符号化されたビデオのビットストリームに含めるように構成されたビットストリーム生成モジュールと、
   を備え、
   前記方向情報は入力画像の全ての画素についての上下反転を示す単一のビットを含み、前記方向情報の持続性に関する持続性情報がフレーム数または画像順序カウント間隔のうち少なくとも１つを含む、
   ビデオエンコードのためのシステム。
5. 前記方向決定モジュールは、方向を示す入力をハンドヘルド装置の一部であるセンサおよびカメラ・ヘッドのうち少なくとも１つから受け取る、請求項４に記載のシステム。
6. 符号化されたビデオのビットストリームから、方向情報を含む補助強化情報（ＳＥＩ）メッセージを抽出し前記方向情報をデコードし、前記符号化されたビデオのビットストリームをデコードして、一連の画像を生成するように構成された方向デコード・モジュールを備え、
   前記方向情報は前記一連の画像のうち少なくとも１つの画像の全ての画素についての上下反転を示す単一のビットを含み、前記方向情報の持続性に関する持続性情報がフレーム数または画像順序カウント間隔のうち少なくとも１つを含む、
   ビデオデコードのためのシステム。
7. 前記方向デコード・モジュールは、前記ビットストリームから抽出されデコードされた前記方向情報に従って少なくとも１つの再構築画像を描画するように構成された描画器に接続された、請求項６に記載のシステム。
8. 前記描画器はグラフィックス・プロセッシング・ユニットを備える、請求項７に記載のシステム。
9. 請求項１、２、または３のうち一項に記載の方法を実施するための命令を含む、非一時的なコンピュータ読取可能媒体。

Images