JP2012085301A - ３次元映像信号処理方法及びこれを具現する携帯型３次元ディスプレイ装置 - Google Patents

Abstract

【課題】ソフトウェアによって高速でステレオスコピック映像信号を処理する方法と、これを具現する３次元ディスプレイ装置を提供する。
【解決手段】本発明は、ディスプレイパネルを含むハードウェア手段を直接制御するカーネル階層と、ハードウェア手段を通じて動画が表出されるようにカーネル階層を制御するアプリケーション/ミドルウェア階層とを具備する携帯型端末機で具現する。平面映像サーフィスをアプリケーション/ミドルウェア階層で生成してデコーディングし、ステレオスコピック映像のペアを表すYUV映像信号を復元する。ついで、RGB映像信号に変換して、カーネル階層でRGB映像信号内に含まれた左映像と右映像をミキシングして、第２フレームバッファに保存する。最後に、カーネル階層で第１及び第２フレームバッファに保存された信号をオーバレイによってハードウェア的に合成してディスプレイパネルに伝達する。
【選択図】 図６

Description

本発明は映像表示装置及び方法に係り、より詳細には、３次元ディスプレイ装置とこのような装置での映像信号処理方法に関する。

人間の視覚システムは多くの奥行き手がかり(depth clue)を使って可視間内で物体の相対的な位置を把握する。このような手がかりは遠近調節(Accommodation)、収斂(Convergence)、両眼視差(Binocular Disparity)、運動視差(Motion Parallax)などの生理的要素と、線形遠近、陰影、濃淡遠近、他の物体による遮蔽、テクスチャ勾配、色相などの心理的要素を含む。生理的奥行き手がかりの中で、遠近調節と言うのは目が３次元空間の特定領域に焦点を合わせようとする時、水晶体の焦点距離を変化させることを言う。

遠近調節は収斂とともに使われる。収斂は観察者が有限の距離にある点を見詰める時二つの目が内側へ移動することによって視線が注視点で交差することを言う。両眼視差は左右側目が約65ミリメートル離れていてお互いに違う映像を受け入れるという事実に起因し、３次元場面を見る時左右側網膜に投射される映像の差を言う。このような両眼視差は視覚システムが奥行き感覚ないし立体視（Stereopsis）で使う決定的な奥行き手がかりになる。

３次元ディスプレイ装置は上記のような人間の視覚認知メカニズムを活用して３次元映像を表示する。多様な３次元映像表示方式が提示されてきたが、本出願が行われる時点で技術的実現可能性と立体感表示能力側面で優れているのはステレオスコピック方式と言える。ステレオスコピック３Ｄディスプレイシステムにおいては、人の目と同じく約64ミリメートル離れた二つのイメージセンサに撮影された２個の映像を人の左眼と右眼に独立的に入力されるようにすることで、両眼視差をシミュレーションして深く知覚または立体視ができるようになる。

いくつかのステレオスコピック映像を構成する２個の映像すなわち、左映像と右映像とが利用者の左眼と右眼とにそれぞれ正確に入力されるようにして干渉を起こさないようにすることが必要である。干渉を排除するための方法では、ディスプレイパネルに位相偏光板を装着して左右映像がお互いに直交する偏光を持つようにして使用者が着する偏光めがねに装着された偏光フィルタが左映像及び右映像がそれぞれ左眼と右眼にだけ入力されるようにする偏光方式、左右映像を相互にディスプレイパネルに表示して使用者の能動型めがねが左眼シャッタと右眼シャッタを相互に開放されるようにするシャッタ方式、レンチキュラレンズによって光の経路を調節するレンチキュラ方式、電気的に発生されたパララックスバリアによって映像を部分的に遮断して左右映像が左眼と右眼とにそれぞれ伝達するようにするパララックスバリア方式などが使われている。

本出願が行われる時点でステレオスコピック３Ｄディスプレイシステムが一番広く実施される形態はテレビ受信機だと言えるが、PC用モニタ、スマートフォン、タブレットPCのようなデータ処理処置でステレオスコピック３Ｄディスプレイを具現するための試みも行われている。データ処理処置での３Ｄ映像信号の処理は通常的にマルチメディアプレーヤのようなアプリケーションプログラムによって成り立つ。ところが、元の映像信号を単純にデコーディングしてフォーマットを変換して再生する２Ｄ映像再生の場合に比べて、３Ｄ映像再生時には３Ｄ映像信号をデコーディングして左映像と右映像とをミキシングする過程を遂行しなければならないのでコンピュータ負担が増加する。

デスクトップPCやノートブックPCのようなデータ処理処置ではマイクロプロセッサの性能が充分に優秀だからアプリケーションプログラムによって３Ｄ映像信号を処理するのに大きな問題はないと言える。これに対してスマートフォンやタブレットタブレットPCのような携帯型機器は、電力電源消費及び発熱などを勘案してPC用プロセッサに比べて処理速度が遅い埋め込みプロセッサを採択しており、このような低速の埋め込みプロセッサではアプリケーションによって３Ｄ映像信号を高性能PCのマイクロプロセッサのように処理することができない。

したがって携帯型機器でアプリケーションプログラムによって３Ｄ映像を再生しようとする場合には、フレーム率ないしビット率や解像度を犠牲にするしかない実情である。特に、アンドロイドプラットフォームを採択する機器と一緒にアプリケーションプログラムがC/C++のようなネイティブコードに作成されているのではなく、ダルビック仮想マシン(DalvicVM)のような仮想マシンの処理するバイナリーコードで作成されている場合には、実行速度の問題がもっと深刻だと言える。同時に、アプリケーションプログラムだけで３Ｄ映像を再生しようとする場合には、プログラムの大きさが大きくなって起動時間が長くなるという問題がある。

これを勘案して、一部機器では埋め込みプロセッサ以外に別途の３Ｄ専用映像信号処理チップセットを付け加えて３Ｄ映像を再生する。この機能ために、例えばアンドロイドプラットフォームの場合にはHAL(Hardware Abstraction Layer)を通じて外部ハードウェアを利用した映像処理及びハードウェア加速機能を具現するようになっている。しかし、追加的な３Ｄ専用チップセットの採択は機器の原価と価格を上昇させ、また印刷基板上の占有空間を増加させるという問題点がある。

本発明はこのような問題点を解決するために、例えばアンドロイドのようなモバイル運営プラットフォームを基盤にする携帯型３次元ディスプレイ装置でプロセッサ以外の追加的なハードウェア使用を最小化しながらソフトウェアによって高速でステレオスコピック映像信号を処理する方法を提供することを技術的課題にする。
また、本発明はモバイル運営プラットフォームを基盤として動作しながら、携帯が可能で、３Ｄ専用チップのような追加的なハードウェアを最小化しながら高速でステレオスコピック映像を再生することができる３次元ディスプレイ装置を提供することを他の技術的課題にする。

前記技術的課題を果たすための本発明の映像信号処理方法の一形態によれば、映像信号処理方法はディスプレイパネルを含むハードウェア手段と、前記ハードウェア手段を直接制御するカーネル階層と、前記ハードウェア手段を通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する携帯型端末機で具現するのに適している。

映像信号を処理するにおいては、まず、一つ以上の平面映像サーフィスをアプリケーション/ミドルウェア階層で生成して第１フレームバッファに保存する。そして、エンコードされた映像信号をアプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する。ついで、前記YUV映像信号をRGB映像信号に変換して、カーネル階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングして、ミキシングされたステレオスコピック映像信号を第２フレームバッファに保存する。最後に、カーネル階層で第１及び第２フレームバッファに保存された信号をオーバレイによってハードウェア的に合成して前記ディスプレイパネルに伝達する。これによってディスプレイパネルを通じてステレオスコピック３次元映像が一般平面映像とともに表出できるようになる。

望ましい実施例において、前記平面映像サーフィスを第１フレームバッファに保存する際には、まず、アプリケーション/ミドルウェア階層で複数の平面映像サーフィスを生成した後、アプリケーション/ミドルウェア階層で前記複数の平面映像サーフィスを合成して前記第１フレームバッファに保存する。

望ましい実施例において、ミキシングされたステレオスコピック映像信号を生成して第２フレームバッファに保存するには、まず、前記YUV映像信号をRGB映像信号に変換してミックスバッファに保存する。そして、ミックスバッファに保存された前記RGB映像信号内に含まれた左映像と右映像とをミキシングして前記ミキシングされたステレオスコピック映像信号をRGBバッファに保存して、前記RGBバッファに保存されているミキシングされたステレオスコピック映像信号が第２フレームバッファに伝達する。ここで、YUV映像信号をRGB映像信号に変換するのはカーネル階層で遂行するのが望ましい。

前記他の技術的課題を果たすための本発明の３次元ディスプレイ装置の一形態によれば、３次元ディスプレイ装置は、元の映像信号を受け入れてデマルチプレクスして圧縮された映像信号を抽出して、前記圧縮された映像信号をデコーディングして表示するために、前面にパララックスバリアを備えるディスプレイパネルと、前記ディスプレイパネルを駆動するディスプレイコントローラと、前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像の少なくとも一部をそれぞれ保存するための第１及び第２フレームバッファと、前記デマルチプレクス動作と前記デコーディング動作とを制御して、前記ディスプレイパネルを直接制御するカーネル階層と、前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する、プログラムを行うマイクロプロセッサとを具備する。

前記マイクロプロセッサは(a)一つ以上の一般平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して前記第１フレームバッファに保存する機能と、(b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する機能と、(c)前記YUV映像信号をRGB映像信号に変換して、前記カーネル階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングして、ミキシングされたステレオスコピック映像信号を前記第２フレームバッファに保存する機能と、(d)前記カーネル階層で前記第１及び第２フレームバッファに保存された信号をオーバレイによってハードウェア的に合成して前記ディスプレイパネルに伝達する機能を遂行する。

上記のような映像信号処理方法は例えばスマートフォンやタブレットPCのようなディスプレイ装置に搭載されて実行することができるプログラムを基盤に具現することができる。前記ディスプレイ装置はディスプレイパネルと、前記ディスプレイパネルを駆動するディスプレイコントローラと、前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像の少なくとも一部を保存するための第１及び第２フレームバッファと、前記ディスプレイパネルを直接制御するカーネル階層と前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する、階層によって所定の機能を遂行するマイクロプロセッサとを具備するのが望ましい。

前記マイクロプロセッサは(a)一つ以上の一般平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して前記第１フレームバッファに保存する機能と、(b)エンコードされた映像信号をデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元させる機能と、(c)前記YUV映像信号をRGB映像信号に変換されるようにして、前記カーネル階層で前記RGB映像信号内に含まれた左映像と右映像とがミキシングされるようにして、ミキシングされたステレオスコピック映像信号が前記第２フレームバッファに保存されるようにする機能と、(d)前記カーネル階層で前記第１及び第２フレームバッファに保存された信号がオーバレイによってハードウェア的に合成されて前記ディスプレイパネルに伝達されるようにする機能とを遂行することができるようになっていることが望ましい。

前記技術的課題を果たすための本発明の映像信号処理方法の他の形態によれば、映像信号処理方法はディスプレイパネルを含むハードウェア手段と、前記ハードウェア手段を直接制御するカーネル階層と、前記ハードウェア手段を通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する携帯型端末機で具現するのに適している。

映像信号を処理するには、まず、一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する。そして、エンコードされた映像信号をアプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する。引き継いで、カーネル階層で前記YUV映像信号をRGB映像信号に変換して、アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングしてミキシングされたステレオスコピック映像信号を立体映像レイヤバッファに保存する。最後に、前記アプリケーション/ミドルウェア階層で平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、フレームバッファを通じて前記ディスプレイパネルに伝達する。これによってディスプレイパネルを通じてステレオスコピック３次元映像が前記平面映像とともに表出できるようになる。

望ましい実施例においては、前記平面映像サーフィスを平面映像レイヤバッファに保存する時、平面映像サーフィスを複数生成して前記複数の平面映像サーフィスそれぞれに対応して用意された複数の平面映像レイヤバッファにそれぞれ保存する。このような場合、映像を合成する時には前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を全て合成するようになる。

前記他の技術的課題を果たすための本発明の３次元ディスプレイ装置の一形態によれば、３次元ディスプレイ装置は前面にパララックスバリアを備えるディスプレイパネルと、前記ディスプレイパネルに表示される映像を保存するフレームバッファと、前記デマルチプレクス動作と前記デコーディング動作とを制御して、前記ディスプレイパネルを直接制御するカーネル階層と、前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層とを具備するプログラムを行うマイクロプロセッサを具備する。

前記マイクロプロセッサは(a)一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する機能と、(b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する機能と、(c)前記カーネル階層で前記YUV映像信号をRGB映像信号に変換して、前記アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングしてミキシングされたステレオスコピック映像信号を立体映像レイヤバッファに保存する機能と、(d)前記アプリケーション/ミドルウェア階層で前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、前記フレームバッファを通じて前記ディスプレイパネルに伝達する機能とを遂行する。

上記のような映像信号処理方法は例えばスマートフォンやタブレットPCのようなディスプレイ装置に搭載して実行することができるプログラムを基盤に具現することができる。前記ディスプレイ装置はディスプレイパネルと、前記ディスプレイパネルを駆動するディスプレイコントローラと、前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像を保存するためのフレームバッファと、前記ディスプレイパネルを直接制御するカーネル階層と前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する階層によって所定の機能を遂行するマイクロプロセッサとを具備するのが望ましい。

前記マイクロプロセッサは(a)一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する機能と、(b)エンコードされた映像信号をデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元させる機能と、(c)前記カーネル階層で前記YUV映像信号をRGB映像信号に変換して、前記アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像とがミキシングされるようにしてミキシングされたステレオスコピック映像信号が立体映像レイヤバッファに保存されるようにする機能と、(d)前記アプリケーション/ミドルウェア階層で前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、フレームバッファを通じて前記ディスプレイパネルに伝達するようにする機能とを遂行することができるようになっていることが望ましい。

本発明によれば、スマートフォンやタブレットPCのような携帯型機器でステレオスコピック映像を再生する際に、ソフトウェア特にミドルウェアとカーネル階層の活用を極大化してステレオスコピック映像信号を処理する。特に、本発明は３Ｄ映像を再生する際に一番長い時間を要する左右映像ミキシング過程をアンドロイドプラットフォームで複数のイメージをブレンディングないしミキシングするプロセスを活用して具現する。これによってPC用プロセッサに比べて処理速度が遅い埋め込みプロセッサを採択する携帯型機器でプロセッサ以外の追加的なハードウェア使用を最小化しながら、フレーム率、ビット率または解像度を犠牲にすることなしに高速で３Ｄ映像を再生することができるようになるという効果がある。

本発明によれば、ソフトウェア階層構造でオペレーティングシステムのカーネルや、ミドルウェアないしライブラリファイルの数または大きさがあまり増加しない長所がある。
同時に、プロセッサ以外の追加的なハードウェア使用が最小化されるから、機器の原価や価格が上昇することを抑制することができるという長所がある。
さらに、望ましい実施例によれば使用者がディスプレイ画面の大きさ、使用者の目とディスプレイの間の距離によって左右映像の間の視差を調節することができるから、めまいなしに３Ｄ映像を視聴することができるようになり、装置の効用と満足度が高くなるという利点がある。

本発明による３次元ディスプレイ装置の一実施例のブロック図。 図１に図示されたマイクロプロセッサによって実行される３Ｄ映像再生プログラムの機能的なブロック図。 左映像と右映像とをミキシングする過程を示す図。 図１のディスプレイ装置で実行されるアンドロイドプラットフォームとアプリケーションに対するレイヤ階層構造を示す図。 図４のレイヤ階層構造において３Ｄ映像ディスプレイのためのジャバ（Ｊａｖａ（登録商標））段及びネイティブ段クラスの構成例を具体的に示すブロック図。 図１のディスプレイ装置でカラースペース変換及び左右映像ミキシングプロセスを具現するための出力端の一実施例の詳細ブロック図。 図６に図示された実施例において３Ｄ映像処理のための関数の実行手順を示す流れ図。 図６に図示された実施例において３Ｄ映像処理のための関数の実行手順を示す流れ図。 図６のミキシングプロセスを採択する実施例における３次元映像表示過程を全体的に示す流れ図。 図１のディスプレイ装置でカラースペース変換及び左右映像ミキシングプロセスを具現するための出力端の他の実施例の詳細ブロック図。 図９に図示された実施例において３Ｄ映像処理のための関数の実行手順を示す流れ図。 図９のミキシングプロセスを採択する実施例における３次元映像表示過程を全体的に示す流れ図。 映像再生の間に画面に表示されるメニューの一例を示す図。

図１を参照すれば、本発明の望ましい実施例による３次元ディスプレイ装置(以下、'ディスプレイ装置'という)はネットワークインターフェース部(10)、不揮発性メモリ(20)、マイクロプロセッサ(30)、揮発性メモリ(40)、LCDコントローラ(50)、LCD パネル(52)、パララックスバリア(54)、バリアコントローラ(56)、タッチパネル(60)、タッチパネルコントローラ(62)を含む。一実施例において、ディスプレイ装置はポータブルマルチメディア再生装置(PMP)である。他の実施例においては、ディスプレイ装置はPMP機能すなわちマルチメディア動画再生機能を具備するスマートフォンやタブレットPCであってもよい。

図１で、ネットワークインターフェース部(10)は例えば802.11b/g/n規格に準拠した無線LANを通じて外部のアクセスポイント装置に接続し、ディスプレイ装置が外部のインターネットサーバと通信できるようにする。特に、本発明において、ネットワークインターフェース部(10)はディスプレイ装置がストリーミングサーバから３Ｄ動画データストリームを受信できるようにする。
不揮発性メモリ(20)は装置内部に固定設置されるか着脱可能に設置され、３Ｄ動画ファイルを保存する。

マイクロプロセッサ(30)はネットワークインターフェース部(10)を通じてストリーミングサーバから受信されるデータストリームまたは不揮発性メモリ(20)に保存されている動画ファイルをデマルチプレクスして圧縮された映像信号を抽出して、この圧縮された動画データをデコーディングして３Ｄ映像信号を復元する。そして、マイクロプロセッサ(30)は３Ｄ映像信号を左右映像信号に分離して左右映像をミキシングする。望ましい実施例において、マイクロプロセッサ(30)によって実行されるデマルチプレクス、デコーディング、ミキシングなどの３Ｄ映像再生過程はアンドロイドプラットフォームと、アンドロイドプラットフォームに基づくアプリケーションプログラムによって具現される。
揮発性メモリ(40)はマイクロプロセッサ(20)の動作過程で発生するデータに対する物理的なバッファ機能を提供する。

一実施例において、メモリ(20)に保存されている動画ファイルはMPEG4形式になっていてもよく、MPEG4コンテナから抽出された映像信号はH.264形式に圧縮されていてもよい。H.264形式に圧縮された映像信号はデコーディング過程を通じて圧縮が解除されてYUVフォーマットの映像信号に変換される。そして、YUVフォーマットの３Ｄ映像信号は後述するマイクロプロセッサ(30)内部のポストプロセッサによってRGBフォーマットに変換されて、LCDパネル(52)に相応する映像の大きさと方向が調整される。これによって、マイクロプロセッサ(30)はRGBフォーマットのサイドバイサイド(Side-by-side)方式３Ｄ映像信号を獲得し、その後左右映像を分離した後ミキシングすることができるようになる。
LCDコントローラ(50)はマイクロプロセッサ(30)からミキシングされた映像信号を受け入れて、ミキシングされた映像がLCDパネル(52)に表示されるようにする。

望ましい実施例において、本発明のディスプレイ装置は偏光めがねやシャッタめがねを使うことは不便であるという携帯型機器の環境を勘案してパララックスバリア方式で左右映像を表出する。図１で、パララックスバリア(54)はLCDパネル(52)の前面に設置されて、LCDパネル(52)を部分的に遮断して左右映像が左眼と右眼にそれぞれ伝達されるようにする。バリアコントローラ(56)はLCDパネル(52)で表出される映像が２Ｄ映像なのか３Ｄ映像なのかによってパララックスバリア(54)を選択的に活性化させて、表出される映像が３Ｄ映像である時にだけパララックスバリア(54)を作動させる。

望ましい実施例において、２Ｄ映像または３Ｄ映像の選択は元の映像信号に含まれた制御信号（例えば、プログラム特定情報(PSI:Program Specific Information)に含まれた映像属性フィールド）に準拠してマイクロプロセッサ(30)によって自動的に遂行される。
一方、図１２に図示されたように映像再生中に画面に表示されるフォーマット選択メニューを通じて使用者が２Ｄ再生または３Ｄ再生中に一つを任意に選択することもできる。

タッチパネル(60)はディスプレイ装置に対する入力機能を提供して、タッチパネルコントローラ(62)はタッチパネル(60)で感知された信号をデジタル座標信号に変換してマイクロプロセッサ(30)に提供する。
図２はマイクロプロセッサ(30)によって実行される３Ｄ映像再生プログラムの機能的なブロック図である。プログラムは機能的にデマルチプレクス部(32)、デコーディング部(34)、ポストプロセッサ(36)、及び左右映像ミキシング部(38)を含む。

デマルチプレクス部(32)はストリーミングサーバから受信されるデータストリームまたは不揮発性メモリ(20)に保存されている動画ファイルをデマルチプレクスして、MPEG4コンテナから圧縮された映像信号を抽出する。一実施例において、MPEG4コンテナから抽出された映像信号はH.264形式に圧縮されていてもよい。一実施例において、デマルチプレクス部(32)は例えば、PacketVideo Co.によって開発されたOpenCORE等のメディアフレームワークで具現される。

デコーディング部(34)は圧縮された映像信号をデコーディングして、３Ｄ映像信号を復元する。一実施形態において、３Ｄ映像信号は左右映像がSide-by-side方式に配置されていて、YUVフォーマットの輝度及びクロミナンスを表現する。望ましい実施例において、デコーディング部(34)はOpenCOREフレームワーク内に含まれるH.264デコーダによって具現され、H.264デコーダはOpenMAXメディアフレームワークによって管理される。

ポストプロセッサ(36)はYUVフォーマットの３Ｄ映像信号を受け入れて、カラースペースをRGBフォーマットに変換して、LCDパネル(52)に適合するように映像の大きさと配向を調整する。望ましい実施例においてはポストプロセッサ(36)がソフトウェアによって構成されるが、変形された実施例においてはポストプロセッサ(36)が２Ｄ映像処理のためのハードウェアチップセット(chipset)で構成されることもできる。
左右映像ミキシング部(38)はポストプロセッサ(36)からRGBフォーマットの３Ｄ映像信号を受け入れて、図３と一緒に左映像と右映像とを垂直ライン単位で相互に配置することで左右映像をパララックスバリア(54)の特性に適合するようにミキシングする。

一方、望ましい実施形態において図２に図示されたデマルチプレクス部(32)、デコーディング部(34)及び左右映像ミキシング部(38)を構成または制御するプログラムは一つのプログラムファイルとして構成されているのではなく、多数のネイティブ(Native)段のサービス(すなわち、アンドロイドプラットフォームのライブラリ)及びカーネル段にある多数のクラスオブジェクトに分散して具現されて、JNI(Java Network Inrerface)を通じてジャバ段(Java)サービス(すなわち、アプリケーションプログラムレベル)でのクラスオブジェクトとインターフェースされる。

図４は図１のディスプレイ装置で実行されるアンドロイドプラットフォームとアプリケーションに対するレイヤ階層構造を示す。
図４及びそのほかの図面と以下の説明において、３Ｄ映像信号の処理に関するアプリケーションはもちろんライブラリ及びアプリケーションプログラムフレームワークはアンドロイド標準に準拠したアプリケーション、ライブラリ及びアプリケーションプログラムフレームワークが本発明によって修正されたものであることに留意しなければならない。すなわち、オープンハンドセットアライアンス(OHA: Open Handset Alliance)が最初に公開された以後、Google社はアンドロイドプラットフォームに関してリナックス(Linux)カーネルと、包括的ライブラリセット、使用者インターフェースに対する標準を決めてこれを保持しており、このようなアンドロイドプラットフォームは完全開放型プラットフォームを志向してソースコードが全て公開されており、誰でもこれを利用してソフトウェアと装置を製作できるようにしている。

特にアンドロイドプラットフォームでの映像再生に関してGoogle社は下記の説明と類似のサービスフレームワークとクラスオブジェクトに対するプロトタイプとを提示している。しかし、サービスフレームワーク及びプロトタイプは２次元映像のブレンディングと２次元的合成のみに対するものであり、本発明者はこのような２次元映像のブレンディングと２次元的合成に関するフレームワークを修正して３次元映像を具現するための左右映像のミキシング方法を発明したことに留意しなければならない。
図４で、アンドロイドプラットフォームはアプリケーションプログラム、アプリケーションプログラムフレームワーク、ライブラリ、リナックスカーネルなどのレイヤを含む。

本発明の望ましい実施例において、アプリケーションプログラムは３Ｄ映像再生を支援するマルチメディアプレーヤ(100)を含む。マルチメディアプレーヤ(100)は全体的な画面構成のための使用者インターフェース(UI)処理関数(102)と、メニュー表示/処理関数(104)と、再生制御関数(106)とを含む。UI処理関数(102)は初期画面と再生中の画面の全体的な構成を決めて使用者要求によって変更する。

特に、望ましい実施例によれば、UI処理関数(102)は図１２に図示されたように操作メニュー(500)を表示することができ、使用者が映像を２Ｄ形式で表示するか３Ｄ形式で表示するか選択するようにして、左右映像間の視差(Disparity)を調整することができるようにし、使用者の選択によって再生制御関数(106)が再生を制御するようにする。

メニュー表示/処理関数(104)は各メニュー段階別で使用者が下位メニューを選択するとか、元のファイルのリソースを選択することができるようにする。このようなマルチメディアプレーヤ(100)はジャババイトコードにプログラミングすることができる。その他に、アドレスインデックス管理、通話、ウェブブラウジングなどのためのアプリケーションプログラムを図１のディスプレイ装置に用意することができる。

アプリケーションプログラムフレームワークはマルチメディアプレーヤ(100)などアプリケーションプログラムで利用することができるAPIを規定しているレイヤである。特に、パッケージマネージャ(110)はマルチメディアプレーヤ(100)のようなアプリケーションプログラムの設置を管理する。アクティビティマネージャ(112)はアプリケーションプログラムのライフサイクルを管理する。

ウィンドウマネージャ(114)はウィンドウすなわち、LCDパネル(52)に表示する全体画面構成を管理する。ビューシステム(116)は使用者インターフェースを管理する。リソースマネージャ(118)は再生する元のデータのリソースを管理する。その他に、アプリケーションプログラムの間のデータ共有を管理するためのコンテンツマネージャ、状態の通知(Alert)表示を管理するための通知マネージャ、通話機能を管理するための通話マネージャ、位置情報を管理するための位置マネージャなどをアプリケーションプログラムフレームワークに用意することができる。

ライブラリ階層は多くのアプリケーションプログラムから汎用的に利用される機能をファイル化した。各アプリケーションプログラムはアプリケーションプログラムフレームワークを通じて各ライブラリファイルを呼び出して行うことができる。特に、サーフィスマネージャ(SurfaceManager;120)は複数の画面を合成するためのライブラリである。メディアフレームワーク(122)は映像ファイルの再生と記録のためのライブラリである。

OpenGL/ESはグラフィックエンジンであり、標準c-ライブラリ(libc;126)は標準的なC言語ライブラリである。その他に、関係型データベースに対するSQLite、ビットマップとベクターフォントのレンダリングを行うFreeType、ブラウザ表示を行うためのHTMLレンダリングエンジンであるWebkit、２ＤグラフィックエンジンであるSGLライブラリ、およびSSLライブラリなどを含むことができる。ライブラリ階層のすべてのライブラリはCまたはC++言語で作成されることが望ましい。

リナックスカーネルはプラットフォームの中枢的な部分として、ディスプレイ装置のハードウェアコンポーネントを制御する。特に、ディスプレイドライバ(130)、オーディオドライバ(132)、キーパッドドライバ(134)、バリアードライバ(136)はそれぞれLCDパネル(52)、スピーカ(図示せず)、タッチパネル(60)、パララックスバリア(54)の動作を制御する。その他に、カメラ、ブルートゥース、フラッシュメモリ、USBインターフェース、WiFiインターフェースなど周辺装置に対するカーネルプログラムと、電力管理プログラムを含むことができる。
一方、図４には図示しなかったが、ジャバ言語に準拠したコアライブラリと、ジャババイトコードを行う仮想マシンであるダルビック(Dalvik)仮想マシンが含まれる。

図４のレイヤ階層構造において、アプリケーションプログラム及びアプリケーションプログラムフレームワークのジャバレイヤは媒介体であるJNI(JavaNativeInterface)を通じてC/C++ライブラリと接続することができる。すなわち、JNIはダルビック仮想マシンの上で動作するアンドロイドアプリケーションプログラムはC/C++のようなネイティブコードで作成されたプログラムに比べて処理速度の遅い短所があるが、JNIを通じてC/C++ネイティブコードライブラリを最大限活用することで処理速度をあげることができるようになる。本発明のディスプレイ装置において、３Ｄ映像再生のためのマルチメディアプレーヤ(100)は２Ｄ映像処理のために用意されているC/C++ネイティブコードライブラリに３Ｄ映像処理機能を追加してJNIを通じて機能を制御するように修正されている。

図５は図４のレイヤ階層構造において３Ｄ映像ディスプレイのためのジャバ段及びネイティブ段クラスの構成例を具体的に示す。便宜上、ネイティブ段の各クラスに含まれる関数を'メソッド'そしてクラスになっていないライブラリプログラムを'関数'と称する。
図５に図示されたクラスをよく見るのに先立って、まず、いくつかの用語について説明する。

アンドロイド標準において、'ビュー(View)'はペイントまたはキーストロークやそのほかの相互作用イベント処理のための四角領域として、使用者インターフェース(UI)のための基本構成単位である。ViewクラスはこのようなView領域を表わして占有する機能を遂行する。
各アクティビティは一つ以上の'ウィンドウ(Window)'を持つことができるし、Windowは一つ以上のサーフィス(Surface)を持つことができる。ここで、Windowは画面に表示されるウィンドウ要素の形態(すなわちlook-and-feel)、位置、メニューなどの構成を表す。Windowクラスは最上位レベルウィンドウの形態と特性、背景などを定義する抽象クラスである。したがってWindowクラスに属する一つのインスタンスが最上位Viewで使われる。

サーフィス(Surface)は画面上にペイントのために用意されてスクリーン合成子(Composer)によって管理されるバッファを意味する。SurfaceはSurfaceViewクラスによって生成されて、Surfaceクラスによってその属性が決まる。
したがって、アプリケーションプログラム遂行の間に複数のSurfaceが生成されて維持されることができるし、SurfaceViewクラスによってこれらの中の一部がWindowとして結合される。この時、すべてのWindowは下端のSurfaceオブジェクトを使って具現される。そして、WindowManagerクラスの制御の下に最上位Windowに係わるSurfaceがフレームバッファに伝達することで、最上位WindowがView領域に表示されると言える。このようなViewないしViewグループを使ってUIと出力映像が構成される。

図５を参照すれば、アプリケーションプログラムであるマルチメディアプレーヤ(100)に含まれるVideoViewクラスインスタンス(200)(以下、'クラスインスタンス'を便宜上'クラス'と称する)はジャババイトコードで作成されて、使用者が再生するメディアをストリーミングサーバまたは不揮発性メモリ(20)から探索して、ファイルの大きさを計算して、ディスプレイオプションを選択することができるようにする。また、VideoViewクラス(200)は使用者入力検出、再生動作の開始、一時停止、再生、終了位置探索などの機能を具現することができるようにする。同時に、VideoViewクラス(200)はマルチメディアプレーヤ(100)の実行が開始される時SurfaceViewクラス(210)に対してサーフィス(Surface)割り当てを要求する。

MediaPlayerクラス(202)はジャババイトコードで作成されて、オーディオ/ビデオファイル及びストリームの再生を制御する。VideoViewクラス(200)によって再生制御機能が選択されれば選択によるパラメータがMediaPlayerクラス(202)に伝達され、これによってMediaPlayerクラス(202)は使用者の選択にしたがってファイル及びストリーム再生を制御するようになる。

SurfaceViewクラス(210)は、ジャババイトコードで作成され、ペイントのためのSurfaceがスクリーンの正確な位置に埋め込み状態に生成されることができるようにし、生成されたsurfaceのフォーマットと大きさを調節することができるようにする。一つのアプリケーションプログラムは一つ以上のSurfaceの割り当てを受けて、特に本発明において、Surfaceはマルチメディアプレーヤ(100)のVideoViewインスタンス(200)の要求によって生成されることができる。Surface割り当てにはWindowManagerクラス(220)が関与することもできる。

SurfaceはSurfaceViewを占有しているウィンドウの背面にZ軸方向すなわちパネル面に垂直である仮想軸に沿って配置される。SurfaceViewクラス(210)はウィンドウにホールドを介してSurfaceが適切にディスプレイされることができるようにする。この時、View階層構造によってSurfaceの合成が正確に管理される。一方、SurfaceはSurfaceViewに係わったWindowが見える(visible)状態にある時生成される。

SurfaceViewクラス(210)の機能はポストプロセッサ(36)を管理するLayerBufferクラス(250)と連動される。また、SurfaceViewクラス(210)はWindowManagerクラス(220)を通じてSurfaceFlingerクラス(262)を制御するように機能する。
Surfaceクラス(212)は、SurfaceViewクラス(210)によってSurfaceが生成される時、生成されるSurfaceに対するぼかし、暗化、回転、隠すこと、フリーズなどのような表示形式を定義する。

SurfaceHolderインターフェース(214)はSurface自体すなわち、Surfaceを占有しているバッファに対する抽象的インターフェースである。SurfaceHolderインターフェース(214)はSurfaceの大きさ及びフォーマットを調節して、Surface内のピクセルを編集するとか、Surfaceに対する変更内容をモニタリングすることができるようにする。

WindowManagerクラス(220)は画面管理のためのJAVAアプリケーションプログラムフレームワークに割り当てられたAPIの一種である。特に本発明によれば、WindowManagerクラス(220)はステレオスコピック映像のペアを構成する左右映像をミキシングするためにネイティブ段のSurfaceComposerクラス(260)を通じてSurfaceFlingerクラス(262)を制御することでSurfaceがフレームバッファに伝達することを制御する。

MediaPlayerクラス(230)はMediaPlayerクラス(202)から伝達されたパラメータによってMediaPlayerServiceクラス(232)が適切なメディアザブシステムないしプレーヤを選択するようにして、MediaPlayerServiceクラス(232)を通じてメディア再生を制御する。また、MediaPlayerクラス(230)はメディアの再生状態をMediaPlayerクラス(202)に知らせる。

MediaPlayerServiceClientクラス(232)はMediaPlayerクラス(230)を通じて伝達されたパラメータによってメディアザブシステム(240)を選択して、再生するメディアをストリーミングサーバまたはメモリ(20)から探索して、探索されたメディアをメディアサブシステム(240)がデマルチプレクスしてデコーディングするようにする。本発明のディスプレイ装置が制御することができるメディアは３Ｄ映像に限定されないし、２次元映像やオーディオであってもよく、これらそれぞれに対して多様なフォーマットの信号を再生することができる。このために、MediaPlayerServiceClientクラス(232)は再生するメディアにふさわしいメディアサブシステム(240)または使用者が前もって選択した種類のサブシステムを選択する。

図５には便宜上一つのメディアサブシステム(240)だけが図示されているが、複数のシステムを用意することができることは上述のとおりである。図示された実施例において、メディアサブシステム(240)はパッケージビデオ社(PacketVideoCorp.)のOpenCOREフレームワークを基に具現されて、PlayerDriverクラス(242)と、PVPlayerクラス(244)と、ビデオコーデック(246)及びオーディオコーデック(図示せず)を含む。

PlayerDriverクラス(242)はPVPlayerクラス(244)に対するスレッドを生成して、PVPlayerクラスがメディアデータをデマルチプレクスしてコンテナから圧縮された映像信号を抽出するようにする。ビデオコーデック(246)はアブプックドエン映像信号をデコーディングして映像信号を復元する。復元された映像信号はYUVフォーマットになっているSide-by-side方式の３Ｄ映像信号であることができる。

AndroidSurfaceOutputクラス(248)はビデオコーデック(246)から出力されるYUV映像信号をLayerBufferクラス(250)に伝達する。
LayerBufferクラス(250)はYUV映像信号に対するビットストリームを受け入れて、以後のRGBカラースペースへの変換と左右映像ミキシング過程に使うようにYUV映像信号データを管理する。

SurfaceComposerクラス(260)はSurfaceFlingerクラス(262)を制御して、ポストプロセッサ(36)によって変換されたRGB映像信号の左右映像がミキシングできるようにする。
SurfaceFlingerクラス(262)は、SurfaceComposerクラス(260)の制御の下に、映像信号をLCDパネル(52)に表示するフレームバッファを管理する。一般的にSurfaceComposerクラス(260)は個別アプリケーションプログラムに割り当てされたSurfaceをフレームバッファに送ることで重層的な(Layered)構造を持つSurfaceを統合する役目を担当する。

図６は図１のディスプレイ装置でカラースペース変換及び左右映像ミキシングプロセスを具現するための出力端の一実施例を示す。図示された出力端のプロセスはステレオスコピック映像のペアを構成する左右映像をミキシングして３Ｄ映像を構成して、この３Ｄ映像とともに一つ以上の一般平面映像を合成(Composition)して出力することができる。ここで、複数の一般平面映像はSurfaceFlingerクラス(262A)によってソフトウェア的に合成(Software Composition)される。そして、合成された平面映像と３Ｄ立体映像とはフレームバッファ(296、298)のオーバレイ機能を通じてLCDコントローラ(50)でハードウェア的に合成(Hardware Composition)される。

第１及び第２レイヤバッファ(270A、270B)はSurfaceFlingerクラス(262A)によって使われるサーフィスバッファとして、ジャバアプリケーションである各種アクティビティによって生成される一般平面映像(すなわち、静止映像)サーフィスをそれぞれ保存する。この平面映像は一般的なレンダリング特性を持った映像として、例えばテキスト、レンダリングされた３Ｄ映像、３Ｄ映像コンテンツ再生過程で付随的に表示されるタイトル情報及びメニュー情報になることができる。

SurfaceFlingerクラス(262A)は複数のサーフィス(Surface)を一つに集めて第１フレームバッファ(296)に送ることで、第１及び第２レイヤバッファ(270A、270B)に保存されたサーフィスデータと一緒に重層的な(Layered)構造のメモリデータを合成する機能を遂行する。

一般平面映像は画面に変化があまり多くないからSurfaceFlingerクラス(262A)がソフトウェア的に合成をしてもシステムに大きく影響を与えない。しかし、動画表示またはカメラ(図１には図示せず)のプレビューを遂行するためのサーフィスをSurfaceFlingerクラス(262A)によって一般平面映像サービスとともに合成すればモバイル運用システムへの負荷が大きくなる原因になる。このため、本実施形態においてSurfaceFlingerクラス(262A)は一般平面映像サーフィスのみを合成して、ミキシングされた３Ｄ映像サーフィスは合成しない。

本実施形態によれば、３Ｄ動画表示またはカメラプレビューを処理するための専用のフレームバッファとして、第２フレームバッファ(298)が用意される。LCDコントローラ(50)は第１及び第２フレームバッファ(296、298)をオーバレイ機能を通じてハードウェア的に合成してLCDパネル(52)に伝達し、これによって非常に早い映像信号処理を可能にする。このような機能を制御するAPIをV4L2(Video4Linux2)と言う。そしてこのようなV4L2APIはLayerBuffer(250)クラスによってAndroidSurfaceOutput(248)クラスに伝達され対応するクラスの制御を受ける。

一方カーネル段には、動画処理のためにYUVバッファ(280)と、ポストプロセッサ(36)と、２Ｄ／３Ｄスィッチ(282A)と、RGBバッファ(284A)と、Mixバッファ(290A)とが追加的に用意されて、映像ミキシングプロセス(292A)が遂行される。
YUVバッファ(280)はLayerBufferクラス(250)を通じてYUV映像信号を受け入れて、ポストプロセッサ(36)はServiceFlingerクラス(262A)またはLayerBufferサービス(250)の管理の下にYUV映像信号をRGB映像信号に変換する。

２Ｄ／３Ｄスィッチ(282A)は再生される映像信号が２Ｄ映像信号の場合にはポストプロセッサ(36)によって出力されるRGB映像信号を直ちにRGBバッファ(284A)に伝達して、再生される映像信号が３Ｄ映像信号の場合にはRGB映像信号をMixバッファ(290A)に伝達して、映像ミキシングプロセス(292A)がRGB映像信号内に含まれた左右映像をミキシングする。

望ましい実施形態において、映像信号が２Ｄ映像信号なのかまたは３Ｄ映像信号なのかの判断は元の映像信号に含まれた制御信号(例えば、プログラム特定情報(PSI: Program Specific Information)に含まれた映像属性フィールド)を基になされる。この判断がアプリケーションプログラム階層で成り立って判断結果を２Ｄ／３Ｄスィッチ(282A)に伝達することもでき、２Ｄ／３Ｄスィッチ(282A)が直接このような判断をすることもできる。一方、映像再生の中に画面に表示されるフォーマット選択メニューを通じて使用者が２Ｄ再生または３Ｄ再生の一つを任意に選択することによって２Ｄ／３Ｄスィッチ(282A)のスイッチング動作を変更することもできる。他方で、端末機に２Ｄ／３Ｄ選択のための機械的スィッチを用意することもできる。

映像ミキシングプロセス(292A)はMixバッファ(290A)に保存されたRGB映像に含まれた左右映像を縦のラインずつミキシングする。本発明の実施例において、映像ミキシングプロセス(292A)はカーネル段で遂行されるプロセスであり、これによって本実施形態における左右映像のミキシングはアンドロイドフレームワーク内のミドルウェア段で処理されるのではなくカーネル段ですぐ処理される。

３Ｄ左右映像のミキシング過程をより具体的によく見れば、映像ミキシングプロセス(292A)はMixバッファ(290A)に保存された映像信号ビットストリームをRGBバッファ(284A)で送る際にビットストリームを順次に送るのではなく、Side-by-sideフォーマットの3DRGB映像で左映像にあたる部分と右映像にあたる部分からピクセルを相互に抽出してコピー(copy)する。すなわち、映像ミキシングプロセス(292A)は図３の左側に図示されたRGB映像で各走査線単位で左映像の第１のピクセルを抽出してRGBバッファ(284A)の第１のピクセル位置に送って、右映像の第１のピクセルを抽出してRGBバッファ(274A)の第２のピクセル位置に配置する。

ついで、映像ミキシングプロセス(292A)はMixバッファ(290A)から左映像の第２のピクセルを抽出してRGBバッファ(284A)の第３のピクセル位置に配置して、右映像の第２のピクセルを抽出してRGBバッファ(284A)の第３のピクセル位置に配置する。このような過程が３ＤのRGB映像全体に対して遂行されることで、RGBバッファ(284A)には左映像と右映像とが垂直ライン単位に相互に配置されたミックスされた映像が保存される。

図６に示されるこのような出力端において、先にSurfaceFlingerクラス(262A)によって処理される一般的なジャバアプリケーション用平面映像サーフィスの流れをよく見れば、それぞれのジャバアプリケーションに割り当てられたサーフィスはソフトウェア的合成機能をするSurfaceFlingerクラス(262A)によって合成されて第１フレームバッファ(296)へ伝達される。

これに対して、動画再生またはカメラプレビューアプリケーション過程で処理されるサーフィスはSurfaceFlingerクラス(262A)によってソフトウェア的な合成をすると性能が低下するため、SurfaceFlinger(262A)を通じないで専用に割り当てされた第２フレームバッファ(298)へ直接的に伝達される。そして、第１及び第２フレームバッファ(296、298)はLCDコントローラ(50)でハードウェア的に合成される。

動画サーフィスに対する処理過程をよく見れば、YUVバッファ(280)に保存されたYUV映像はポストプロセッサ(36)によってRGB映像に変換されてLCDパネル(52)の画面大きさに当たるようにスケーリングされる。２Ｄ／３Ｄスィッチ(282A)が２Ｄモードに設定されていれば、一般的な２Ｄ映像はRGBバッファ(284A)にすぐ保存された後第２フレームバッファ(298)から伝達する。一方、２Ｄ／３Ｄスィッチ(282A)が３Ｄモードに設定されていれば、ポストプロセッサ(36)から出力されたRGB映像はMixバッファ(290A)にコピーされる。Mixバッファ(290A)に保存された映像内に含まれる左右映像は映像ミキシングプロセス(292A)によってミキシングされた後RGBバッファ(284A)に保存される。

その後、RGBバッファ(284A)に保存されているミキシングされたRGBビットストリームは動画専用の第２フレームバッファ(298)へ伝達される。二つのフレームバッファ(296、298)に保存されたデータはオーバレイによってLCDコントローラ(50)でハードウェア的に合成される。合成された３Ｄ映像はLCDパネル(52)に表示されることで、パララックスバリア(54)の前面にいる使用者がタイトル名称及び/またはメニューとともにステレオスコピック３Ｄ映像を認識することができるようになる。

本実施形態によれば、３Ｄ動画のミキシングに係わったSurfaceの流れがミドルウェア段すなわち、Native段にコピーされないでカーネル段ですぐ処理され、またSurfaceFlingerクラス(262A)によってソフトウェア的に合成されないので全般的な処理時間が短縮される効果がある。
図７ａ及び図７ｂは図６に図示された実施例において３Ｄ映像処理のための関数の実行手順を示す。

ビデオコーデック(246)からデコーディングされたYUV映像信号がタイマ同期に従って出るようになれば、AndroidSurfaceOutputクラス(250)からオーディオとの同期のために決まった時間ごとにメンバ関数であるwriteAsync()関数が実行される(ステップ300)。writeAsync()関数はデコーディングされたYUV映像信号のRGB信号への変換のためにポストプロセッサのバッファに映像信号をコピーするようにWriteFrameBuffer()関数を呼び出す(ステップ302)。WriteFrameBuffer()関数はデコーディングされたメディアビットストリームをLayerBufferクラス(250)のサブクラスであるSurfaceLayerBufferクラスに伝達する。

デコーディングされたYUV映像信号ビットストリームはSurfaceLayerBufferクラス内にいるpostBuffer()関数によってLayerBufferクラス(250)に伝達され(ステップ304)、またLayerBufferクラス(250)内にいるpostBuffer()関数によってLayerBufferクラス(250)の他のサブクラスであるBufferSourceクラスに伝達される(ステップ306)。
BufferSourceクラスのpostBuffer()関数はYUV映像信号ビットストリームがYUVバッファ(280)に保存された状態でポストプロセッサ(36)を制御してポストプロセッサ(36)がYUV映像信号をRGB映像信号に変換するようにして(ステップ308)、このためにpostBuffer()関数はV4L2APIを呼び出す。

ステップ310ないしステップ324ではYUV映像信号をRGB映像信号で変換するための関数が階層構造に乗って呼び出しされて、結局ステップ324でポストプロセッサ(36)にYUVのRGBへの変換を始めるようにする制御信号が付与されてRGBへのカラースペース変換が成り立つ。
第一に、ステップ310では、YUV映像のビットストリームを送るデータの物理的アドレスがBufferSourceクラス内のfimc_set_DMA_address()関数によって設定される。
ステップ312でYUV信号をRGB信号で変換するのに使うバッファの大きさがfimc_V4L2_queue()関数によって定義された後、カーネル段のデバイスドライバを実行させるためのioctl()関数が呼び出しされて実行される(ステップ314)。

ステップ316からのプログラム流れはカーネル段のV4L2インターフェースドライバによって遂行されるカーネル段のデバイスドライバでのカーネルプロセスである。ステップ316で、カーネル段のV4L2インターフェースドライバが駆動され始めて、変換したYUV信号のソースとポストプロセッサ(36)の状態を確認する。そして、V4L2_ioctl()関数によってポストプロセッサ(36)がオープンされる。fimc_qbuf()関数は現在遂行しているタスクの種類が例えば'ビデオキャプチャ'なのか'ビデオ出力'なのかを確認して、'ビデオ出力'タスクが遂行されている場合fimc_qbuf_output()関数を呼び出す(ステップ318)。

fimc_qbuf_output()関数はバッファ状態がポストプロセッサ(36)へのDMAが可能か否かを確認した後バッファをインコミングキューに追加する(ステップ320)。ついで、カラースペースの変換する領域の位置がfimc_qbuf_output_dma_auto()関数によって更新されながら(ステップ322)、fimc_outdev_start_camif()関数によってポストプロセッサ(36)によるRGB変換作業が進行される(ステップ324)。
ステップ326ないしステップ330はポストプロセッサ(36)がYUVでRGBへのカラースペース変換を完了した後発生する割り込みによって実行される割り込み処理ルーチンとして左右映像ミキシング過程を行う段階である。

それぞれのフレームに対してYUV映像からRGB映像でのカラースペース変換が完了する度に、ポストプロセッサ(36)内で割り込みが発生されてfimc_irq()関数が呼び出しされる(ステップ326)。'ビデオ出力'モード下で、fimc_irq()関数はFimc_irq_out()関数を呼び出して(ステップ328)、この関数はFimc_irq_out_dma()関数を呼び出す。
Fimc_irq_out_dma()関数はRGBビットストリームに対して左右映像ミキシング過程を行った後RGBバッファ(284A)を経て第２フレームバッファ(298)で送る(ステップ330)。

これをより詳しく説明すれば、RGBビットストリームが順次に送信されるのではなく、Side-by-sideフォーマットの３ＤのRGB映像で左映像にあたる部分と右映像にあたる部分からピクセルが相互に抽出されて送信される。すなわち、Fimc_irq_out_dma()関数は映像の各走査線単位で左映像の第１のピクセルを抽出してRGBバッファ(284A)の第１のピクセル位置に送って、右映像の第２のピクセルを抽出してRGBバッファ(284A)の第２のピクセル位置に配置する。ついで、Fimc_irq_out_dma()関数は左映像の第２のピクセルを抽出してRGBバッファ(284A)の第３のピクセル位置に配置して、右映像の第２のピクセルを抽出してRGBバッファ(284A)の第４のピクセル位置に配置する。このような過程が映像全体に実行されることで左右映像がミキシングされて、RGBバッファ(284A)には左映像と右映像とが垂直ライン単位に相互に配置されてミックスされた映像が保存される。
Fimc_irq_out_dma()関数によって、ミキシングされたRGBビットストリームは動画専用の第２フレームバッファ(298)でDMA送信することができる。

図８は図６のミキシングプロセスを採択する実施例における３次元映像表示過程を全体的に示す。
使用者はマルチメディアプレーヤ(100)の実行を選択した後ファイルを選択する(ステップ350)。この時、ファイルを先に選択してマルチメディアプレーヤ(100)が実行されるようにすることもできる。

ステップ352で、マルチメディアプレーヤ(100)のVideoViewクラス(200)はSurfaceViewクラス(210)に対してSurface割り当てを要請する。SurfaceViewクラス(210)はSurfaceを生成、管理するものの直接生成するのではなく、Surfaceを総合的に管理するWindowManagerクラス(220)にSurfaceを要請する。要請を受けたWindowManagerクラス(220)はJNIインターフェースを通じてSurfaceFlingerクラス(262)にSurfaceを要請して、SurfaceFlingerクラス(262)がSurfaceを割り当てる。割り当てされたSurfaceはこれを実際に使うMediaPlayer(230)に伝達することができる状態になる。

ステップ354で、VideoViewクラス(200)はMediaPlayerクラス(202)を通じて映像再生を行うMediaPlayerエンジン(244)を捜す。これによって、例えばPVPlayerを選択することができる。VideoViewクラス(200)は選択されたMediaPlayerエンジン(244)に割り当てされたSurfaceと選択されたファイルを伝達する。ついで、PVPlayer(244)は実行の準備をして、PlayerDriver(242)を通じてOpenCOREフレームワーク内にいるビデオコーデック(246)が実行されるようにする。そして、PVPlayer(244)は出力で使うSurfaceとAndroidSurfaceOutputクラス(246)を通じて接続する。

ステップ356ではPVPlayer(244)が実行されることによって元のデータに対するデマルチプレクス及びデコーディングが成り立つ。ここで、元のデータはストリーミングサーバから受信されるデータストリームであってもよく、または、メモリ(20)に保存されているマルチメディアファイルとして、映像、オーディオ、データなど複数のコンテンツが複合的に構成されたコンテナ構造を持っていてもよい。PVPlayer(244)は元のデータをデマルチプレクスしてコンテナ内にある動画ソースを抽出して、ビデオコーデック(246)は圧縮された状態の動画ソースをデコーディングされてYUVビデオフレームデータを出力する。出力されるYUV映像信号はPlayerDriver(242)及びAndroidSurfaceOutputクラス(248)を通じてLayerBufferクラス(250)に伝達される。

ステップ358で、LayerBufferクラス(250)に伝達されたYUV映像信号はその下部サービスであるSurfaceLayerBufferクラスの制御の下にポストプロセッサ(36)によってRGB映像信号に変換される。ポストプロセッサ(36)に変換されたRGB映像信号は割り当てされたSurfaceバッファすなわち、RGBバッファ(284A)に伝達される。

RGB映像信号が２Ｄ映像信号の場合、映像信号はRGBバッファ(284A)でカーネル段の第２フレームバッファ(298)に伝達された後、LCDコントローラ(50)で一般平面映像に相応するサーフィス(Surface1、Surface2)とハードウェア合成された後、LCDパネル(52)を通じて映像として表出される。一方、RGB映像信号が３Ｄ映像信号の場合には、SurfaceFlingerクラス(262)はRGB映像信号へのカラースペース変換が完了した映像に対してオーバレイ機能を遂行するようにポストプロセッサ(36)のオーバレイクラスを実行させる。これによって、RGB映像信号内に含まれた左右映像のペアはピクセル単位に相互にミキシングされてRGBバッファ(284A)に保存された後、第２フレームバッファ(298)からDMA送信される。ミキシングされたRGB映像は第１フレームバッファ(296)内に保存された一般平面映像に相応するサーフィス(Surface1、Surface2)とLCDコントローラ(50)で合成された後、LCDパネル(52)を通じて３Ｄ映像として表出されて立体効果を現わすようになる(ステップ360)。
ステップ356ないしステップ360は元のデータの再生が完了するまで繰り返し遂行される。

図９は図１のディスプレイ装置でカラースペース変換及び左右映像ミキシングプロセスを具現するための出力端の他の実施例を示す。図示された出力端のプロセスはステレオスコピック映像のペアを構成する左右映像をミキシングして３Ｄ映像を構成して、この３Ｄ映像とともに一つ以上の一般平面映像を合成(Composition)して出力することができる。ここで、複数の一般平面映像と３Ｄ映像とはすべてSurfaceFlingerクラス(262B)によってソフトウェア的に合成される。

本実施形態において、ネイティブ段には第１ないし第３レイヤバッファ(270A〜270C)と、２Ｄ／３Ｄスィッチ(282B)と、Mixバッファ(290B)が用意されて、映像ミキシングプロセス(292B)が遂行される。
第１及び第２レイヤバッファ(270A、270B)はSurfaceFlingerクラス(262B)によって使われる一般的なサーフィスバッファとして、ジャバアプリケーションである各種アクティビティによって生成される一般平面映像サーフィスをそれぞれ保存する。平面映像は一般的なレンダリング特性を持った映像として、例えばテキスト、レンダリングされた３Ｄ映像、３Ｄ映像コンテンツ再生過程で付随的に表示されるタイトル情報及びメニュー情報とすることができる。

第３レイヤバッファ(270C)は３Ｄ動画表示またはカメラプレビューを処理するためのバッファである。第３レイヤバッファ(270C)に保存される動画データはカーネル段から供給することができる。カーネル段で、YUVバッファ(280)はLayerBufferクラス(250)を通じてYUV映像信号を受け入れて、ポストプロセッサ(36)はServiceFlingerクラス(262B)またはLayerBufferサービス(250)の管理の下にYUV映像信号をRGB映像信号に変換する。変換されたRGB映像信号はRGBバッファ(284B)に保存される。

２Ｄ／３Ｄスィッチ(282B)は再生される映像信号が２Ｄ映像信号の場合にはRGBバッファ(284B)に保存されたRGB映像信号を直ちに第３レイヤバッファ(270C)に伝達して、再生される映像信号が３Ｄ映像信号の場合にはRGB映像信号をMixバッファ(290B)に伝達して映像ミキシングプロセス(292B)がRGB映像信号内に含まれた左右映像をミキシングするようにする。ミキシングされたRGB映像信号は第３レイヤバッファ(270C)に保存される。

左右映像のミキシング過程をより具体的によく見れば、映像ミキシングプロセス(292B)はMixバッファ(290B)に保存された映像信号ビットストリームを第３レイヤバッファ(270C)に送るに際しビットストリームを順次に送るのではなく、Side-by-sideフォーマットの３ＤのRGB映像で左映像にあたる部分と右映像にあたる部分からピクセルを相互に抽出してコピー(copy)する。すなわち、映像ミキシングプロセス(292B)は各走査線単位で左映像の第１のピクセルを抽出して第３レイヤバッファ(270C)の第１のピクセル位置に送って、右映像の第１のピクセルを抽出して第３レイヤバッファ(270C)の第２のピクセル位置に配置する。

ついで、映像ミキシングプロセス(292B)はMixバッファ(290B)から左映像の第２のピクセルを抽出して第３レイヤバッファ(270C)の第３のピクセル位置に配置して、右映像の第２のピクセルを抽出して第３レイヤバッファ(270C)の第４のピクセル位置に配置する。このような過程が３ＤのRGB映像全体に対して遂行されることで、第３レイヤバッファ(270C)には左映像と右映像が垂直ライン単位に相互に配置されたミックスされた映像が保存される。

SurfaceFlingerクラス(262B)は一般平面映像サーフィス(Surface1、Surface2)とともに動画サーフィス(Surface3)を一つに集めてフレームバッファ(296)にレンダリングすることで、第１ないし第３レイヤバッファ(270A〜270C)に保存された重層的な(Layered)構造のデータを合成する機能を遂行する。
このような出力端において、一般的なジャバアプリケーション用平面映像サーフィスの流れをよく見れば、それぞれのジャバアプリケーションに割り当てされたサーフィスはソフトウェア的合成機能をするSurfaceFlingerクラス(262B)によって合成されてフレームバッファ(296)に伝達される。

本実施形態によれば、動画再生またはカメラプレビューアプリケーション過程で処理されるサーフィス(Surface3)もSurfaceFlingerクラス(262B)によってソフトウェア的に合成される。
動画サーフィスに対する処理過程をよく見れば、YUVバッファ(280)に保存されたYUV映像はポストプロセッサ(36)によってRGB映像に変換されてLCDパネル(52)の画面大きさにあうようにスケーリングされる。２Ｄ／３Ｄスィッチ(282B)が２Ｄモードに設定されていれば、一般的な２Ｄ映像は第３レイヤバッファ(270C)にすぐ保存された後、SurfaceFlingerクラス(262B)に伝達され、他のサーフィスとともに合成されてフレームバッファ(296)に伝達される。

一方、２Ｄ／３Ｄスィッチ(282B)が３Ｄモードに設定されていれば、RGBバッファ(284B)に保存されたRGB映像はネイティブ段のMixバッファ(290B)にコピーされる。Mixバッファ(290B)に保存されているミキシングされたRGB映像内の左右映像は映像ミキシングプロセス(292B)によってミキシングされた後第３レイヤバッファ(270C)伝達される。そしてミキシングされたRGB映像はSurfaceFlingerクラス(262B)に伝達され、他のサーフィスとともに合成されてフレームバッファ(296)に伝達されることで、LCDパネル(52)にタイトル名称及び/またはメニューとともに３Ｄ映像として表示される。

以後、第３レイヤバッファ(270C)に保存された3DRGBビットストリームはSurfaceFlingerクラス(262B)に伝達されて他のSurfaceと合成される。合成された映像はフレームバッファ(296)に伝達されてLCDコントローラ(50)を通じてLCDパネル(52)に表示されることで、パララックスバリア(54)の前面にいる使用者にステレオスコピック３Ｄ映像が認知されることができるようになる。

本実施形態によれば動画Surfaceの流れがミドルウェアすなわち、Native段にコピーされて処理されてSurfaceFlingerクラス(262B)によって他のサーフィスによってソフトウェア的に合成されるから、図６に図示された実施形態に比べて全体的な合成処理時間が少し増えるが、小型LCDを具備する端末機、またはリアルタイムの映像ではなくアニメーション映像特にレンダリングによるポリゴン数が少ないアニメーション映像を処理する端末機に相応して使うことができる。

図１０は図９に図示された実施例において３Ｄ映像処理のための関数の実行手順を示す。
ビデオコーデック(246)からデコーディングされたYUV映像信号がタイマ同期に従って出るようになれば、AndroidSurfaceOutputクラス(250)で決まった時間ごとにメンバ関数であるwriteAsync()関数が実行される(ステップ300)。writeAsync()関数はデコーディングされたYUV映像信号のRGB信号への変換のためにポストプロセッサのバッファに映像信号をコピーするようにWriteFrameBuffer()関数を呼び出す(ステップ302)。

WriteFrameBuffer()関数はデコーディングされたメディアビットストリームをLayerBufferクラス(250)のサブクラスであるSurfaceLayerBufferクラスに伝達する。
デコーディングされたYUV映像信号ビットストリームはSurfaceLayerBufferクラス内のpostBuffer()関数によってLayerBufferクラス(250)に伝達され(ステップ304)、またLayerBufferクラス(250)内のpostBuffer()関数によってLayerBufferクラス(250)の他のサブクラスであるBufferSourceクラスに伝達される(ステップ306)。
BufferSourceクラスのpostBuffer()関数はYUV映像信号ビットストリームがYUVバッファ(280)に保存された状態でポストプロセッサ(36)を制御してポストプロセッサ(36)がYUV映像信号をRGB映像信号に変換するようにする(ステップ308)。

YUV映像信号からRGB映像信号への変換が完了すれば、LayerBufferクラス(250)のonDraw()コールバック関数が呼び出しされる(ステップ410)。onDraw()関数はSide-by-sideフォーマットの3DRGB映像で左映像にあたる部分と右映像にあたる部分からピクセルを相互に抽出して新しいSurfaceに挿入、配置する。すなわち、onDraw()関数は映像の各走査線単位で第１の左映像ピクセルを抽出して新しいSurfaceの第１のピクセル位置に配置して、第１の右映像ピクセルを抽出して新しいSurfaceの第２のピクセル位置に配置する。

ついで、onDraw()関数は第２の左映像ピクセルを抽出して新しいSurfaceの第２のピクセル位置に配置して、第２の右映像ピクセルを抽出して新しいSurfaceの第４のピクセル位置に配置する。このような過程が映像全体に対して遂行されることで、左右映像がミキシングされて新たに形成された画面では左映像と右映像とが垂直ライン単位に相互に配置することができるようになる。
左右RGB映像のミキシングが完了すれば、BufferSourceサービスのonDraw()関数は完了信号をSurfaceFlingerクラス(262B)で伝達して、SurfaceFlingerクラス(262B)がミキシングされたRGB映像データを他のサーフィス(Surface1、Surface2)と一緒にフレームバッファ(296)に出力することができるようにする(ステップ412)。

図１１は図９のミキシングプロセスを採択する実施例における３次元映像表示過程を全体的に示す。
使用者はマルチメディアプレーヤ(100)の実行を選択した後ファイルを選択する(ステップ450)。この時、ファイルを先に選択してマルチメディアプレーヤ(100)が実行されるようにすることもできる。

ステップ452で、マルチメディアプレーヤ(100)のVideoViewクラス(200)はSurfaceViewクラス(210)に対してSurface割り当てを要請する。SurfaceViewクラス(210)はSurfaceを生成、管理するものの直接生成するのではなく、Surfaceを総合的に管理するWindowManagerクラス(220)にSurfaceを要請する。要請を受けたWindowManagerクラス(220)はJNIインターフェースを通じてSurfaceFlingerクラス(262)にSurfaceを要請して、SurfaceFlingerクラス(262)がSurfaceを割り当てる。割り当てされたSurfaceはこれを実際に使うMediaPlayer(230)に伝達することができる状態になる。

ステップ454で、VideoViewクラス(200)はMediaPlayerクラス(202)を通じて映像再生を行うMediaPlayerエンジン(244)を捜す。これによって、例えばPVPlayerを選択することができる。VideoViewクラス(200)は選択されたMediaPlayerエンジン(244)に割り当てされたSurfaceと選択されたファイルを伝達する。ついで、PVPlayer(244)は選択されたファイルを再生する準備をして、PlayerDriver(242)を通じてOpenCOREフレームワーク内にいるビデオコーデック(246)が実行されるようにする。そして、PVPlayer(244)は出力で使うSurfaceとAndroidSurfaceOutputクラス(246)を通じて接続する。

ステップ456ではPVPlayer(244)が実行されることによって元のデータに対するデマルチプレクス及びデコーディングが成り立つ。ここで、元のデータはストリーミングサーバから受信されるデータストリームであってもよく、または、メモリ(20)に保存されているマルチメディアファイルとして、映像、オーディオ、データなど複数のコンテンツが複合的に構成されたコンテナ構造を持っていてもよい。PVPlayer(244)は元のデータをデマルチプレクスしてコンテナ内にある動画ソースを抽出して、ビデオコーデック(246)は圧縮された状態の動画ソースをデコーディングしてYUVビデオフレームデータとして出力する。出力されるYUV映像信号はPlayerDriver(242)及びAndroidSurfaceOutputクラス(248)を通じてLayerBufferクラス(250)に伝達される。

ステップ458で、LayerBufferクラス(250)に伝達されたYUV映像信号はその下部サービスであるSurfaceLayerBufferクラスの制御の下にポストプロセッサ(36)によってRGB映像信号に変換される。ポストプロセッサ(36)に変換されたRGB映像信号は割り当てされたSurfaceバッファすなわち、RGBバッファ(284B)伝達される。
RGB映像信号が２Ｄ映像信号の場合、映像信号はSurfaceFlingerクラス(262B)の制御の下に第３レイヤバッファ３(270C)に伝達された後SurfaceFlingerクラス(262B)によって一般平面映像サーフィス(Surface1、Surface2)とソフトウェア的に合成される。合成された映像信号はフレームバッファ(296)に伝達されることで、LCDパネル(52)を通じて映像として表出される。

一方、RGB映像信号が３Ｄ映像信号の場合には、RGBバッファ(284B)に保存されたRGB映像信号がMixバッファ(290B)にコピーされて、映像ミキシングプロセス(292B)を通じてミキシングされる。ミキシングされた3DRGB映像は第３レイヤバッファ３(270C)に伝達された後SurfaceFlingerクラス(262B)によって一般平面映像サーフィス(Surface1、Surface2)とソフトウェア的に合成される(ステップ460)。合成された映像信号はフレームバッファ(296)を経てLCDパネル(52)を通じて映像として表出されて、パララックスバリア(54)の作用によって映像が立体効果を表すようになる。
ステップ456ないしステップ460は元のデータの再生が完了するまで繰り返し遂行される。

本発明の３Ｄディスプレイ装置でマルチメディアプレーヤ(100)はLCDパネル(52)上に表示されるUI上に実行アイコンとして存在することができる。アイコンが選択されれば、プログラムが実行されながら再生することができるファイルリストが表示されて、ファイルを選択すればファイルが再生される。一方、ウェブサイトに接続した状態で、メディアファイルを選択するとかメディアファイルが含まれたページを選択すれば該当のメディアファイルがストリーミング方式で提供される。

望ましい実施形態においては、図１２に図示されたように映像再生中に画面に操作メニュー(500)を表示させることができる。操作メニュー(500)は'開始/一時停止'ボタン(502)と、'再開'ボタン(504)と、'前画面に移動'ボタン(506)と、'２Ｄ／３Ｄ選択'ボタン(508)と、'視差(Disparity)増加'ボタン(510)と、'視差減少'ボタン(512)を含むことができる。ここで、'前画面に移動'ボタン(506)は動画を再生以前での画面移動を指示するのに使われる。

'２Ｄ／３Ｄ選択'ボタン(508)は使用者が２Ｄ映像を表示するか、３Ｄ映像を表示するかを指示するのに使われる。'視差(Disparity)増加'ボタン(510)と'視差減少'ボタン(512)は左右映像間の視差(Disparity)を調整するための操作ボタンである。使用者が'視差増加'ボタン(510)を押せば左右映像ミキシングの時に適用するオフセット値が増加する。すなわち、使用者が'視差(Disparity)増加'ボタン(510)を押せば、ミキシング過程で左映像に対して右映像を右側で１ピクセルシフトさせた後ミキシングを遂行する。

一方、使用者が'視差減少'ボタン(512)を押せば左右映像ミキシングの時に適用するオフセット値が減少する。すなわち、使用者が'視差減少'ボタン(512)を押せば、ミキシング過程で左映像に対して右映像を左側で１ピクセルシフトさせた後ミキシングを遂行する。これによってLCDパネル(52)の大きさや使用者の視聴習慣、特に使用者の両眼とLCDパネル(52)の距離によって最適の視差が形成されるようにすることでめまいを減少させて３Ｄ映像の満足度を高めることができるようになる。

以上で本発明の望ましい実施形態を説明したが、本発明はその技術的思想や必須特徴を変更しなくても多様な方式で変形することができるし他の具体的な形態で実施することができる。
例えば、以上の説明では元のファイルまたはストリーミングデータがH.264規格にエンコードされている場合を中心に説明したが、他の規格にエンコードされたファイルないしストリーミングデータをデコーディングすることもできる。
また、入力映像がSide-by-side方式でフォーマットされることを基準に説明したが、入力映像がTop-down方式、タイル方式またはそのほかの方式でフォーマットされていても類似の方式で映像信号を処理することができる。

望ましい実施形態ではポストプロセッサがソフトウェアによって具現される実施形態を中心に説明したが、このような実施形態が変形された実施形態ではポストプロセッサをハードウェア的に構成することもできるのは勿論である。
一方、メディアフレームワークとしてOpenCOREを使う実施形態を説明したが、OpenCOREが複雑で修正変換がとても難しい点を勘案して、アンドロイドプラットフォームによってはOpenCOREの代りにStagefrightを使うこともできてそのほかのフレームワークを使うこともできる。

図９ないし図１１の実施例と係わって、カラースペース変換だけがカーネル段で成り立って左右映像のミキシングはミドルウェアで成り立つ場合を中心に説明したが、カラースペース変換とともに左右映像のミキシングもカーネル段で成り立つことができる。
なお、上述しなかったが、フレームバッファ(296、298)はマイクロプロセッサ(30)に用意することもできて、LCDコントローラ(50)に用意することもできる。フレームバッファ(296、298)がLCDコントローラ(50)に用意される場合、特許請求の範囲における“ディスプレイコントローラ”は、LCDパネル(52)の発光動作を遂行して、フレームバッファ(296、298)の映像ビットストリームが直接またはオーバレイによってLCDパネル(52)に伝達することを調節するコア機能遂行部を称する意味で使われる。

本発明によるディスプレイ装置を具現するためのアプリケーションプログラム及びライブラリプログラムユニットは記録媒体に記録された状態で提供されることで、パララックスバリアを具備するか着脱可能に具備することができる端末機に搭載されて実行されることができる。ここで、端末機は携帯型端末機に限定されるのではなくてTV、デスクトップPC、ノートブックPCなど固定型ないし半固定型端末機も含まれる。

したがって、上述した実施例はすべての面で例示的なものであり限定的ではないものとして理解しなければならない。本発明の範囲は前述の詳細な説明よりは特許請求の範囲によって現わされ、特許請求の範囲の意味及び範囲そしてその等価概念から導出されるすべての変更または変形された形態が本発明の範囲に含まれると解釈されなければならない。

Claims (16)

1. ディスプレイパネルを含むハードウェア手段と、前記ハードウェア手段を直接制御するカーネル階層と、前記ハードウェア手段を通じて動画が表出されるように前記カーネル階層を制御するアプリケーション／ミドルウェア階層を具備する携帯型端末機において３次元映像信号を処理する方法であって、前記方法は、
   (a)一つ以上の平面映像サーフィスを前記アプリケーション/ミドルウェア階層から生成して、第１フレームバッファに保存する段階と、
   (b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する段階と、
   (c)前記YUV映像信号をRGB映像信号に変換して、前記カーネル階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングして、ミキシングされたステレオスコピック映像信号を第２フレームバッファに保存する段階と、
   (d)前記カーネル階層で前記第１及び第２フレームバッファに保存された信号をオーバレイによってハードウェア的に合成して前記ディスプレイパネルに伝達する段階とを含み、前記ディスプレイパネルを通じてステレオスコピック３次元映像が前記一般平面映像とともに表出されるようにすることを特徴とする３次元映像信号処理方法。
2. 前記(a)段階が、
   前記アプリケーション/ミドルウェア階層で複数の平面映像サーフィスを生成する段階と、前記アプリケーション/ミドルウェア階層で前記複数の平面映像サーフィスを合成して前記第１フレームバッファに保存する段階とを含むことを特徴とする請求項１に記載の３次元映像信号処理方法。
3. 前記(c)段階が、
   (c1)前記YUV映像信号を前記RGB映像信号で変換してミックスバッファに保存する段階と、
   (c2)前記ミックスバッファに保存された前記RGB映像信号内に含まれた前記左映像と前記右映像をミキシングして前記ミキシングされたステレオスコピック映像信号をRGBバッファに保存して、前記RGBバッファに保存された前記ミキシングされたステレオスコピック映像信号が前記第２フレームバッファに伝達するようにする段階とを含むことを特徴とする請求項１に記載の３次元映像信号処理方法。
4. 前記(c1)段階が前記カーネル階層で遂行されることを特徴とする請求項３に記載の３次元映像信号処理方法。
5. 元の映像信号を受け入れてデマルチプレクスして圧縮された映像信号を抽出して、前記圧縮された映像信号をデコーディングして表示するディスプレイ装置であって、
   前面にパララックスバリアを備えるディスプレイパネルと、
   前記ディスプレイパネルを駆動するディスプレイコントローラと
   前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像の少なくとも一部をそれぞれ保存するための第１及び第２フレームバッファと、
   前記デマルチプレクス動作と前記デコーディング動作とを制御し、前記ディスプレイパネルを直接制御するカーネル階層と、前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層とを具備するプログラムを行うマイクロプロセッサとを備え、
   前記マイクロプロセッサは、
   (a)一つ以上の一般平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して前記第１フレームバッファに保存する機能と、
   (b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する機能と、
   (c)前記YUV映像信号をRGB映像信号に変換して、前記カーネル階層で前記RGB映像信号内に含まれた左映像と右映像をミキシングして、ミキシングされたステレオスコピック映像信号を前記第２フレームバッファに保存する機能と、
   (d)前記カーネル階層で前記第１及び第２フレームバッファに保存された信号をオーバレイによってハードウェア的に合成して前記ディスプレイパネルに伝達する機能とを遂行して、前記ディスプレイパネルを通じてステレオスコピック３次元映像を表出することを特徴とする携帯型３次元ディスプレイ装置。
6. 前記マイクロプロセッサが前記(a)処理機能を遂行するに際し、複数の平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して合成して前記第１フレームバッファに保存することを特徴とする請求項５に記載の携帯型３次元ディスプレイ装置。
7. 前記マイクロプロセッサの(c)処理機能が、
   (c1)前記YUV映像信号を前記RGB映像信号に変換してミックスバッファに保存する機能と、
   (c2)前記ミックスバッファに保存された前記RGB映像信号内に含まれた前記左映像と前記右映像とをミキシングして前記ミキシングされたステレオスコピック映像信号をRGBバッファに保存して、前記RGBバッファに保存された前記ミキシングされたステレオスコピック映像信号が前記第２フレームバッファに伝達するようにする機能とを含むことを特徴とする請求項５に記載の携帯型３次元ディスプレイ装置。
8. 前記(c1)処理機能が前記カーネル階層で遂行されることを特徴とする請求項７に記載の携帯型３次元ディスプレイ装置。
9. ディスプレイパネルと、前記ディスプレイパネルを駆動するディスプレイコントローラと、前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像の少なくとも一部を保存するための第１及び第２フレームバッファと、前記ディスプレイパネルを直接制御するカーネル階層と前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層とを具備する階層によって所定の機能を遂行するマイクロプロセッサとを具備するディスプレイ装置に搭載され、前記マイクロプロセッサによって実行されるプログラムとして、
   (a)一つ以上の一般平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して前記第１フレームバッファに保存する機能と、
   (b)エンコードされた映像信号をデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元させる機能と、
   (c)前記YUV映像信号をRGB映像信号に変換されるようにして、前記カーネル階層で前記RGB映像信号内に含まれた左映像と右映像とがミキシングされるようにして、ミキシングされたステレオスコピック映像信号が前記第２フレームバッファに保存されるようにする機能と、
   (d)前記カーネル階層で前記第１及び第２フレームバッファに保存された信号がオーバレイによってハードウェア的に合成されて前記ディスプレイパネルに伝達するようにする機能とを具備して、前記ディスプレイパネルを通じてステレオスコピック３次元映像が表出されるようにする携帯型端末機用プログラムを記録したことを特徴とする記録媒体。
10. 前記(a)機能を遂行するに際し、複数の平面映像サーフィスを前記アプリケーション/ミドルウェア階層で生成して合成し、前記第１フレームバッファに保存されるようにするプログラムを記録したことを特徴とする請求項９に記載の記録媒体。
11. ディスプレイパネルを含むハードウェア手段と、前記ハードウェア手段を直接制御するカーネル階層と、前記ハードウェア手段を通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層とを具備する携帯型端末機において、３次元映像信号を処理する方法であって、前記方法は、
    (a)一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する段階と、
    (b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する段階と、
    (c)前記カーネル階層で前記YUV映像信号をRGB映像信号に変換して、前記アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像をミキシングしてミキシングされたステレオスコピック映像信号を立体映像レイヤバッファに保存する段階と、
    (d)前記アプリケーション/ミドルウェア階層で前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、フレームバッファを通じて前記ディスプレイパネルに伝達する段階とを含み、前記ディスプレイパネルを通じてステレオスコピック３次元映像が前記平面映像とともに表出されるようにすることを特徴とする３次元映像信号処理方法。
12. 前記(a)段階で、前記平面映像サーフィスを複数生成して前記複数の平面映像サーフィスそれぞれに対応して用意された複数の平面映像レイヤバッファにそれぞれ保存して、前記(d)段階で、前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成することを特徴とする請求項１１に記載の３次元映像信号処理方法。
13. 元の映像信号を受け入れてデマルチプレクスして圧縮された映像信号を抽出して、前記圧縮された映像信号をデコーディングして表示するディスプレイ装置であって、
    前面にパララックスバリアを備えるディスプレイパネルと、
    前記ディスプレイパネルに表示される映像を保存するフレームバッファと
    前記デマルチプレクス動作と前記デコーディング動作とを制御して、前記ディスプレイパネルを直接制御するカーネル階層と、前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する、プログラムを行うマイクロプロセッサとを備え、
    前記マイクロプロセッサは、
    (a)一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する機能と、
    (b)エンコードされた映像信号を前記アプリケーション/ミドルウェア階層の関与の下にデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元する機能と、
    (c)前記カーネル階層で前記YUV映像信号をRGB映像信号に変換して、前記アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像とをミキシングしてミキシングされたステレオスコピック映像信号を立体映像レイヤバッファに保存する機能と、
    (d)前記アプリケーション/ミドルウェア階層で前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、前記フレームバッファを通じて前記ディスプレイパネルに伝達する機能とを遂行して、前記ディスプレイパネルを通じてステレオスコピック３次元映像を表出することを特徴とする携帯型３次元ディスプレイ装置。
14. 前記マイクロプロセッサが前記(a)処理機能を遂行する際には、前記平面映像サーフィスを復数個生成して前記平面映像サーフィスそれぞれに対応して用意された複数の平面映像レイヤバッファにそれぞれ保存して、前記(d)処理機能を遂行する際には前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成することを特徴とする請求項１３に記載の携帯型３次元ディスプレイ装置。
15. ディスプレイパネルと、前記ディスプレイパネルを駆動するディスプレイコントローラと、前記ディスプレイコントローラを通じて前記ディスプレイパネルに表示される映像を保存するためのフレームバッファと、前記ディスプレイパネルを直接制御するカーネル階層と前記ディスプレイパネルを通じて動画が表出されるように前記カーネル階層を制御するアプリケーション/ミドルウェア階層を具備する階層によって所定を機能を遂行するマイクロプロセッサを具備するディスプレイ装置に搭載されて実行可能なプログラムとして、
    (a)一つ以上の平面映像サーフィスを生成して、平面映像レイヤバッファに保存する機能と、
    (b)エンコードされた映像信号をデコーディングして、ステレオスコピック映像のペアを表すYUV映像信号を復元させる機能と、
    (c)前記カーネル階層で前記YUV映像信号をRGB映像信号で変換して、前記アプリケーション/ミドルウェア階層で前記RGB映像信号内に含まれた左映像と右映像とがミキシングされるようにしてミキシングされたステレオスコピック映像信号が立体映像レイヤバッファに保存されるようにする機能と、
    (d)前記アプリケーション/ミドルウェア階層で前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成して、フレームバッファを通じて前記ディスプレイパネルに伝達するようにする機能とを具備して、前記ディスプレイパネルを通じてステレオスコピック３次元映像が表出されるようにする携帯型端末機用プログラムを記録したことを特徴とする記録媒体。
16. 前記(a)機能を遂行する際に、前記平面映像サーフィスを複数生成して前記複数の平面映像サーフィスそれぞれに対応して用意された複数の平面映像レイヤバッファにそれぞれ保存して、前記(d)機能を遂行するにおいては前記平面映像レイヤバッファ及び立体映像レイヤバッファに保存された信号を合成するプログラムを記録したことを特徴とする請求項１５に記載の記録媒体。

Images