情報処理装置、情報処理方法及びプログラム
【課題】複数の映像ストリームのフレーム単位での再生ずれを抑える。
【解決手段】本開示に係る情報処理装置は、時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、を備える。
【解決手段】本開示に係る情報処理装置は、時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、例えば下記の特許文献１には、複数の通信を受信側で同期させて受信することを想定した技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−１６４９１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１に記載された技術では、送信側が付与した同期データを受信側で処理しなければならないため、処理が煩雑となり、処理負荷が高くなるという問題がある。また、この方式では、ジッタに起因して発生する複数のストリームのフレーム単位での再生ずれを抑えることはできない。
【０００５】
そこで、複数ストリームのフレーム単位で再生ずれを抑えることが求められていた。
【課題を解決するための手段】
【０００６】
本開示によれば、時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、を備える、情報処理装置が提供される。
【発明の効果】
【０００７】
本開示によれば、複数のストリームのフレーム単位で再生ずれを抑えることが可能となる。
【図面の簡単な説明】
【０００８】
【図１】左目用映像と右目用映像とからなる立体映像を別々にストリーミングし、ＩＰネットワークを介して受信側の装置に送信するシステムの一例を示す模式図である。
【図２】送信側端末の構成を示す模式図である。
【図３】受信側端末の構成を示す模式図である。
【図４】トランスポートストリームの構成を示す模式図である。
【図５】ＩＰネットワークを用いたシステムでのデコードの仕組みを示す模式図である。
【図６】ＳＴＣとＰＴＳの値に基づいてフレーム表示を行う様子を示す模式図である。
【図７】ジッタが大きい場合にフレーム表示を行う様子を示す模式図である。
【図８】３Ｄの映像データでフレームずれが発生した場合を示す模式図である。
【図９】フレームずれを検知する処理を示すフローチャートである。
【図１０】フレームずれから回復させる処理を示すフローチャットである。
【図１１】フレームずれから回復する様子を示す模式図である。
【発明を実施するための形態】
【０００９】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１０】
なお、説明は以下の順序で行うものとする。
１．前提となる技術
２．送信側、受信側の端末構成
３．トランスポートストリームの構成
４．フレーム表示の例
５．フレームずれを検知する処理
６．フレームずれを回復する処理
【００１１】
１．前提となる技術
先ず、本実施形態の前提となる技術について説明する。図１は、左目用映像と右目用映像とからなる立体映像を別々にストリーミング（３Ｄデュアルストリーミング）し、ＩＰネットワークを介して受信側の装置に送信するシステムの一例を示している。
【００１２】
図１に示す構成において、３Ｄカメラ１０２で撮影された左目映像と右目映像は、送信側で別々に設けられたエンコーダ１１０，１２０により各々が同期してエンコードされ、ＲＴＰパケット等にパケット化された後、ＩＰネットワーク３００を介して受信側の機器へストリーミングされる。なお、図１では、同一のＩＰネットワーク３００を介して左目映像と右目映像がストリーミングされる様子を示しているが、左目映像と右目映像は別のネットワークを介して別経路でストリーミングされても良い。受信側の機器では、左目映像と右目映像を別々のデコーダ２１０，２２０で同期デコードし、表示部（ディスプレイ）２３０に表示する。
【００１３】
なお、映像をスクリーンに投影する場合は、デコーダ２１０，２２０で同期デコードされた映像データが、左目用プロジェクタと右目用プロジェクタ（不図示）にそれぞれ入力される。そして、左目映像が左目用プロジェクタで投影され、右目映像が右目用プロジェクタで投影される。
【００１４】
表示部２３０は、左目映像と右目映像を所定周期で交互にスクリーン上に投影する。映像をスクリーンに投影する場合、左目用プロジェクタ及び右目用プロジェクタは、左目映像と右目映像を所定周期で交互にスクリーン上に投影する。立体映像を視認するユーザは、左目と右目の前に液晶シャッターを備えるシャッター眼鏡を装着する。シャッター眼鏡は、表示画面上で左目映像と右目映像が切り換わる周期と同期して左右の液晶シャッターを交互に開閉する。そして、左目映像が表示されるタイミングでは、ユーザの左目の前の液晶シャッターのみが開かれ、右目映像が表示されるタイミングでは、ユーザの右目の前の液晶シャッターのみが開かれる。これにより、ユーザの左目には左映像が視認され、右目には右目映像が視認されることとなり、ユーザは立体映像を視認することができる。
【００１５】
図１に示すような複数の映像をストリーミングする構成では、送信側のエンコーダ１１０，１２０では複数の映像を同じタイミングで同期エンコード処理し、受信側のデコーダ２１０，２２０では同じタイミングで同期デコード処理する。ＩＰネットワーク３００上でジッタが少なく、複数のストリームが到着する遅延時間が少ない状態であれば、同期エンコード処理と同期デコード処理を行うことで、３Ｄデュアルストリームの映像を同期して再生することが可能である。
【００１６】
しかし、複数映像のストリーミングの際にジッタ、遅延、パケットロス等が発生すると、同期デコードすべきタイミングでコンテンツが受信側のデコーダ２１０，２２０に入力されない状態が発生し、左右の再生される映像がフレーム単位でずれてしまう。また一度左右の映像がフレーム単位でずれてしまうと、その後の映像もフレーム単位でずれた状態のままとなり、同期デコードを行うことができなくなる。
【００１７】
以上のように、複数映像のストリーミングを行う場合、パケットロス、ネットワーク３００におけるジッタ、遅延の影響等により、いずれか一方の映像が他方に対して遅延した状態で受信側の装置に到達ししまうことが考えられる。この場合、左映像と右映像のフレームにずれが生じてしまい、所望の立体映像を表示することが困難となる。このため、以下に説明する本実施形態では、フレームにずれが生じた場合は、これを検出し、回復させる処理を行う。以下、詳細に説明する。
【００１８】
２．送信側、受信側の端末構成
図２及び図３は、送信側と受信側の端末の構成をそれぞれ示す模式図である。図２及び図３に示す各構成要素は、ハードウェア（回路）、またはＣＰＵなどの中央演算処理装置と、これを機能させるためのプログラムから構成することができる。この場合に、そのプログラムは、端末が備えるメモリなどの記憶部に格納されることができ、また、ディスク状記憶媒体、ＵＳＢメモリなど外部から挿入される記憶媒体に格納されることができる。図２は、送信側端末１００の構成を示す模式図である。送信側端末１００は、左目映像のエンコーダ１１０、左目映像のネットワークインタフェース１３０、右目映像のエンコーダ１２０、右目映像のネットワークインタフェース１４０、同期エンコード処理部１５０、を備える。
【００１９】
左目映像のエンコーダ１１０と右目映像のエンコーダ１２０は、同期エンコード処理部１５０が発生する同期クロックに基づいて動作し、左右の映像（左目映像及び右目映像）を同期してエンコードする。エンコードされた左右の映像は、ＲＴＰパケットなどにパケット化され、左右のネットワークインターフェース１３０，１４０から受信側端末２００に送信される。例えばエンコードしたデータをＭＰＥＧ２システムに入れる場合において、同期エンコード処理部１５０が発生する同期したクロックに基づきエンコーダ１１０，１２０が動作している場合、同じフレームの映像に関しては同じＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が付与される。
【００２０】
図３は、受信側端末２００の構成を示す模式図である。受信側端末２００は、左目映像のデコーダ２１０、右目映像のデコーダ２２０、左目映像のネットワークインタフェース２５０、左目映像のバッファ２６０、右目映像のネットワークインタフェース２７０、右目映像のバッファ２８０、フレームずれ検知処理部２８２、フレームずれ回復処理部２８４、を備える。また、受信側端末２００は、クロック２９０、ＰＷＭ２９２を備える。
【００２１】
ネットワークインタフェース２５０は、送信側端末１００から送られた左目映像のＲＴＰパケットを受信する。ネットワークインタフェース２７０は、送信側端末１００から送られた右目映像のＲＴＰパケットを受信する。受信した左目映像のＲＴＰパケットはバッファ２６０に送られ、受信した右目映像のＲＴＰパケットはバッファ２８０に送られる。そして、ネットワークインターフェース２５０，２７０から受信したＲＴＰパケットは、バッファ２６０，２８０を経由して同期デコードを行っているデコーダ２１０，２２０に送信される。
【００２２】
発振器２９０は、一定の周期でクロック信号を発生させる。デコーダ２１０，２２０は、発振器２９０が発生するクロック信号に基づいて、左目映像と右目映像の同期デコードを行う。
【００２３】
ここで、ＩＰネットワーク３００でのジッタや遅延がバッファ２６０，２８０で吸収できる程度の大きさであれば、デコーダ２１０，２２０が同期デコードし続けることは可能であるが、バッファ２６０，２８０の許容量を超えるジッタや遅延がある場合は、フレームずれが発生する。
【００２４】
３．トランスポートストリームの構成
図４は、トランスポートストリームの構成を示す模式図である。図４に示すように、映像データ（ビデオ符号化データ）は、ＭＰＥＧ２システムのＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）に分割される。送信側端末１００のエンコーダ１１０，１２０は、映像データの１フレームを複数のＴＳに分割し、先頭のＴＳにＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）を記述することで、受信側端末２００のデコーダ２１０，２２０側がフレームを表示すべきタイミングを通知する。ＰＴＳは、トランスポートストリームのＴＳヘッダに挿入される。また、メディア間の同期をとるためのＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）情報、ＰＡＴ，ＰＭＴ等のプログラム情報などもＴＳパケットに分割される。また、図４に示すように、ＩＰネットワーク３００上でＴＳを送信する際には、ＴＳパケットの前にＲＴＰヘッダとＩＰヘッダを追加して送信する。
【００２５】
なお、放送波などでは、遅延が少なく、ジッタが少なく、ロスがほとんど起きない環境下では、ＳＴＣをＰＣＲのクロックに同期させて、フレームを同期させることができる。しかし、ＩＰネットワーク３００のようにジッタが大きくパケットロスが多い環境下では、ＰＣＲを用いたクロック同期を行うことができない。
【００２６】
図５は、本実施形態のようなＩＰネットワーク３００を用いたシステムでのデコードの仕組みを示す模式図である。ＩＰネットワーク３００では、放送波のようなＰＣＲを用いたクロック同期を行うことはできないので、ＰＣＲの値とは独立してクロックコントロールを行う。受信側端末２００は、ＰＷＭ２９２により発振器（ＶＣＸＯ）２９０を制御し、デコーダ２１０，２２０にクロック信号を入力する。デコーダ２１０，２２０は、入力されたクロック信号に基づいてＳＴＣ（システムクロック）をカウントアップし、ネットワークインターフェース２５０，２７０から受信したＴＳのＰＴＳに基づいてフレームの表示を行う。このときのＰＷＭのコントロール方法は、バッファサイズの遷移などの方法で行うことが可能である。
【００２７】
４．フレーム表示の例
図６は、ＳＴＣとＰＴＳの値に基づいてフレーム表示を行う様子を示す模式図である。図６において、Ｐ１，Ｐ２，Ｐ３・・・は、１フレームのＴＳパケットを示している。図６に示す構成では、ＳＴＣとＰＴＳが厳密な同期を行うことはできないので、ＰＴＳとＳＴＣは絶対時間では一致しない。そこでフレームを表示は、ＳＴＣの差分値とＰＴＳの差分値が一致した時に行う。図６に示すように、フレームを表示すべきタイミングＳＴＣ１，
ＳＴＣ２においては、ＳＴＣ１，ＳＴＣ２のタイミングよりも前に到着したＴＳパケットで構成されるＰ１，Ｐ２のフレームを表示している。例えば、３０フレーム／ｓのフレームレートで表示を行う際にＳＴＣ１が０［ｓ］のタイミングでＰＴＳが２０ｍｓの映像フレームを表示したとすると、次のフレームを表示するＳＴＣ２は３３ｍｓとなるので、ＰＴＳの値が５５ｍｓと記述されているＴＳパケットで構成されるフレームをＳＴＣ２のタイミングで表示する。
【００２８】
図７は、ジッタが大きい場合にフレーム表示を行う様子を示す模式図である。ＰＴＳが記述されたＴＳパケットの到着タイミングがジッタにより遅れてしまうと、フレームを表示すべきタイミングで該当のフレームが表示できなくなる。図７に示す例では、ＳＴＣ３のタイミングでＰ３のフレームが到着していないため、ＳＴＣ３のタイミングでＰ３のフレームを表示することができない。次のＳＴＣ４のタイミングでどのフレームを表示するかはデコーダの仕様次第ではあるが、ＩＰネットワーク３００ではルーティング変更によりパケット到着が定常的に遅くなる可能性があることを考慮すると、バッファに蓄積されているＰ３のフレームをＳＴＣ４のタイミングで表示し、その後は新たなＰＴＳとＳＴＣの差分値に基づいてフレーム表示を行うことになる。
【００２９】
図７に示すようなジッタが発生した場合においても、２Ｄ映像の場合は、ストリーミングする映像データが１つであるため、複数映像におけるフレームずれの問題は生じない。しかしながら、複数の映像データをストリーミングする場合、ある映像データが他のデータに対して遅れてしまう問題が発生する。例えば、３Ｄデュアルストリーミングでフレーム同期を行う場合、一方のストリーミングデータのみにジッタが発生すると、一方の映像に対して他方の映像が遅れて表示されてしまう。
【００３０】
図８は、３Ｄの映像データでフレームずれが発生した場合を示す模式図である。左映像のＰ３のフレームのジッタが大きい場合、Ｐ３のフレームを表示すべきタイミング（ＳＴＣ３）で、左映像のＰ３のフレームを表示することができない。ＩＰネットワーク３００に対応したデコーダを用いている場合、次のＳＴＣ４のタイミングで右映像はＰ４のフレームを表示するのに対して、左映像はＰ３のフレームを表示する。この後のフレームも同様に、ＳＴＣの差分とＰＴＳの差分に基づいて表示することから、常にフレームずれの状態が継続してしまう。
【００３１】
このため、本実施形態では、フレームずれ検知処理部２８２が、左目映像と右目映像のデコーダ２１０，２２０のデータからフレームずれの発生を検知する。そして、フレームずれ検知処理部２８２は、左目映像と右目映像にフレームずれが発生している場合は、その旨をフレームずれ回復処理部２８４に通知する。フレームずれ回復処理部２８４は、フレームずれが生じている旨の通知を受けると、左目映像と右目映像のバッファ２６０，２８０に対してフレームずれの回復処理を行う。
【００３２】
５．フレームずれを検知する処理
図９は、フレームずれを検知する処理を示すフローチャートである。図９に示す処理は、フレームずれ検知処理部２８２が主として行う。先ず、ステップＳ１０では、フレーム更新タイミングが到来したか否かを判定する。フレーム更新タイミングは、エンコードした映像データのフレームレートに応じて一定の値に定められており、図６〜図８等に示したＳＴＣ１，ＳＴＣ２，ＳＴＣ３，・・・に対応する。例えば、３０ｐのフレームレートであれば３３．３ｍｓ毎にフレームが更新される。ステップＳ１０において、フレーム更新タイミングが到来した場合はステップＳ１２へ進む。一方、ステップＳ１０において、フレーム更新タイミングが到来していない場合は、ステップＳ１０で待機する。
【００３３】
ステップＳ１２に進んだ場合、フレーム更新タイミングにおいて、フレームずれ検知処理部２８２は、２つのデコーダ２１０，２２０から、デコーダ２１０，２２０が表示部２３０に現在表示している左目映像と右目映像のフレームのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）を取得する。次のステップＳ１４では、ステップＳ１２で取得した２つのＰＴＳを比較する。
【００３４】
ステップＳ１４での比較の結果、２つのＰＴＳが異なる場合は、ステップＳ１６へ進む。この場合、フレームずれ検知処理部２８２は、左右の映像のフレームがずれていると判定する。例えば、図８のＳＴＣ４では、左目映像がＰ４のフレームであり、右目映像がＰ３のフレームであるため、左目映像と右目映像のフレームのＰＴＳが異なり、左右の映像のフレームがずれていると判定する。
【００３５】
一方、ステップＳ１４での比較の結果、２つのＰＴＳが等しい場合は、ステップＳ１０へ戻り、以降の処理を再度行う。
【００３６】
６．フレームずれを回復する処理
図１０は、フレームずれが発生した場合に、これを回復させる処理を示すフローチャットである。図１０に示す処理は、フレームずれ回復処理部２８４が主として行う。図８で説明したように、フレームずれが発生した後に映像をデコーダ２１０，２２０にそのまま送信し続けると、デコーダ２１０，２２０で再生されるフレームが互いにずれた状態が継続されてしまう。このため、フレームずれ回復処理部２８４は、フレームずれ検知処理部２８２により左右の映像のフレームがずれていると判定された場合は、バッファ２６０，２８０に対して映像データを廃棄し続けるように指示する（ステップＳ２０）。映像データを廃棄する方法としては、例えば映像のコンテンツデータがＴＴＳの場合、ＴＴＳパケットのタイムスタンプとシステムクロックを比較して、クロックと同じＴＴＳパケットを廃棄する方法で行うことができる。また、バッファ２６０，２８０内部のデータをすべて廃棄するという方法を用いてもよい。
【００３７】
次に、ステップＳ２２では、フレーム更新タイミングが到来したか否かを判定する。フレーム更新タイミングが到来した場合は、ステップＳ２４へ進む。一方、フレーム更新タイミングが到来していない場合は、ステップＳ２２で待機する。
【００３８】
ステップＳ２４では、フレーム更新タイミングにおいて、２つのデコーダ２１０，２２０の双方で映像が更新されていないか、を判定する。２つのデコーダ２１０，２２０のいずれか一方で映像が更新されている場合は、そのデコーダのバッファ（デコーダバッファ）の中に映像データが存在しているため、ステップＳ２２へ進み、次のフレーム更新タイミングまで待機する。一方、２つのデコーダ２１０，２２０の双方で映像フレームが更新されていない場合は、デコーダバッファが空になっているので、ステップＳ２６へ進み、再度２つのバッファ２６０，２８０からデコーダ２１０，２２０への映像の送信を再開する。
【００３９】
図１０の処理によれば、２つのデコーダ２１０，２２０の双方で映像フレームが更新されていない状態となるまでは、バッファ２６０，２８０に蓄積された映像データの廃棄が継続される。従って、ジッタ等によるフレームずれが生じた場合は、フレームずれが生じた映像データを廃棄することができる。以上のように、フレームずれが生じている場合は、バッファ２６０，２８０に対して回復（廃棄）処理を行うことで、フレームずれを解消することができる。
【００４０】
バッファに蓄積された映像データが廃棄され続けると、デコーダ２１０，２２０に新たに映像データが入力されない状態となり、２つのデコーダ２１０，２２０の双方において、デコードされてデコーダバッファから出力される映像フレームが更新されない状態となる。そして、デコーダ２１０，２２０の双方で映像フレームが更新されていない状態になると、バッファ２６０，２８０からデコーダ２１０，２２０への映像の送信が再開される。これにより、バッファ２６０，２８０からデコーダ２１０，２２０へ同期した映像フレームの送信を再開することができる。
【００４１】
図１１は、本実施形態の手法により、左右のフレームがずれた状態から回復する様子を示す模式図である。図１１では、左映像のフレームＰ３の到着がジッタ等により遅延した場合を示している。ＳＴＣ４のタイミングでは、右映像についてはフレームＰ４が表示されるが、左映像はフレームＰ３が表示される。このため、ＳＴＣ４のタイミングでは、デコーダ２１０，２２０のそれぞれで取得されるＰＴＣの値が異なり、フレームずれ検知処理部２８２により左右のフレームがずれていることが検知される。
【００４２】
フレームずれ回復処理部２８４は、ＳＴＣ４のタイミングでバッファ２６０，２８０に蓄積されている映像フレームを廃棄する。このため、ＳＴＣ４以降に到着したフレームＰ５は、左右のバッファ２６０，２８０において廃棄される。次のフレーム表示タイミングＳＴＣ５において、デコーダ２１０，２２０の双方で左右映像のフレームの更新が行われていない場合は、バッファ２６０，２８０に到着したパケットのデコーダ２１０，２２０への送信を再開する。これにより、図８の仕組みに基づいて、ＰＴＳの差分情報がクリアされ、次に左右で再び同期されたフレームが表示される。
【００４３】
以上説明したように本実施形態によれば、フレーム単位で同期をとる必要がある複数ストリームの映像を、別のＩＰネットワーク経由で配信しても、受信側で同期を取って再生することが可能になる。また、受信側でフレーム単位の同期がずれた場合に、自動で検知することが可能となり、同期ずれを自動で回復することが可能になる。
【００４４】
なお、上述した実施形態では、複数のストリーミングデータとして３Ｄの左右映像を例示したが、例えば４Ｋの映像を１９２０×１０８０ピクセルの４つの映像に分割し、各々を別のネットワークを介して送信する場合などにも利用することができ、分割したデータの同期を確保することが可能である。
【００４５】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００４６】
なお、本技術は以下のような構成も取ることができる。
（１）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、
前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、
を備える、情報処理装置。
【００４７】
（２）前記複数の映像データストリームのそれぞれをデコードするデコーダを備え、
前記ずれ検出部は、前記デコーダでデコードされた前記複数の映像データストリームのそれぞれのＰＴＣを映像のフレーム毎に比較して、前記複数の映像データストリームの時間的なずれを検出する、前記（１）に記載の情報処理装置。
【００４８】
（３）前記複数の映像データストリームのデータをそれぞれ蓄積するバッファを備え、
前記ずれ回復処理部は、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、前記バッファに蓄積された前記複数の映像データストリームのデータを消去する、前記（１）に記載の情報処理装置。
【００４９】
（４）前記ずれ回復処理部は、前記デコーダ内に前記複数の映像データストリームのデータが存在しなくなった時点で、前記バッファに蓄積された前記複数の映像データストリームのデータ消去を停止する、前記（３）に記載の情報処理装置。
【００５０】
（５）前記複数の映像データストリームは、左目映像の映像データストリームと右目映像の映像データストリームとから構成される、前記（１）に記載の情報処理装置。
【００５１】
（６）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信すること、
前記複数の映像データストリームの時間的なずれを検出することと、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うことと、
を備える、方法。
【００５２】
（７）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する手段、
前記複数の映像データストリームの時間的なずれを検出する手段、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行う手段、
をコンピュータに実行させるためのプログラム。
【符号の説明】
【００５３】
２００ 受信側端末
２１０，２２０ デコーダ
２５０，２７０ ネットワークインターフェース
２６０，２８０ バッファ
２８２ フレームずれ検知処理部
２８４ フレームずれ回復処理部
【技術分野】
【０００１】
本開示は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、例えば下記の特許文献１には、複数の通信を受信側で同期させて受信することを想定した技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−１６４９１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１に記載された技術では、送信側が付与した同期データを受信側で処理しなければならないため、処理が煩雑となり、処理負荷が高くなるという問題がある。また、この方式では、ジッタに起因して発生する複数のストリームのフレーム単位での再生ずれを抑えることはできない。
【０００５】
そこで、複数ストリームのフレーム単位で再生ずれを抑えることが求められていた。
【課題を解決するための手段】
【０００６】
本開示によれば、時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、を備える、情報処理装置が提供される。
【発明の効果】
【０００７】
本開示によれば、複数のストリームのフレーム単位で再生ずれを抑えることが可能となる。
【図面の簡単な説明】
【０００８】
【図１】左目用映像と右目用映像とからなる立体映像を別々にストリーミングし、ＩＰネットワークを介して受信側の装置に送信するシステムの一例を示す模式図である。
【図２】送信側端末の構成を示す模式図である。
【図３】受信側端末の構成を示す模式図である。
【図４】トランスポートストリームの構成を示す模式図である。
【図５】ＩＰネットワークを用いたシステムでのデコードの仕組みを示す模式図である。
【図６】ＳＴＣとＰＴＳの値に基づいてフレーム表示を行う様子を示す模式図である。
【図７】ジッタが大きい場合にフレーム表示を行う様子を示す模式図である。
【図８】３Ｄの映像データでフレームずれが発生した場合を示す模式図である。
【図９】フレームずれを検知する処理を示すフローチャートである。
【図１０】フレームずれから回復させる処理を示すフローチャットである。
【図１１】フレームずれから回復する様子を示す模式図である。
【発明を実施するための形態】
【０００９】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１０】
なお、説明は以下の順序で行うものとする。
１．前提となる技術
２．送信側、受信側の端末構成
３．トランスポートストリームの構成
４．フレーム表示の例
５．フレームずれを検知する処理
６．フレームずれを回復する処理
【００１１】
１．前提となる技術
先ず、本実施形態の前提となる技術について説明する。図１は、左目用映像と右目用映像とからなる立体映像を別々にストリーミング（３Ｄデュアルストリーミング）し、ＩＰネットワークを介して受信側の装置に送信するシステムの一例を示している。
【００１２】
図１に示す構成において、３Ｄカメラ１０２で撮影された左目映像と右目映像は、送信側で別々に設けられたエンコーダ１１０，１２０により各々が同期してエンコードされ、ＲＴＰパケット等にパケット化された後、ＩＰネットワーク３００を介して受信側の機器へストリーミングされる。なお、図１では、同一のＩＰネットワーク３００を介して左目映像と右目映像がストリーミングされる様子を示しているが、左目映像と右目映像は別のネットワークを介して別経路でストリーミングされても良い。受信側の機器では、左目映像と右目映像を別々のデコーダ２１０，２２０で同期デコードし、表示部（ディスプレイ）２３０に表示する。
【００１３】
なお、映像をスクリーンに投影する場合は、デコーダ２１０，２２０で同期デコードされた映像データが、左目用プロジェクタと右目用プロジェクタ（不図示）にそれぞれ入力される。そして、左目映像が左目用プロジェクタで投影され、右目映像が右目用プロジェクタで投影される。
【００１４】
表示部２３０は、左目映像と右目映像を所定周期で交互にスクリーン上に投影する。映像をスクリーンに投影する場合、左目用プロジェクタ及び右目用プロジェクタは、左目映像と右目映像を所定周期で交互にスクリーン上に投影する。立体映像を視認するユーザは、左目と右目の前に液晶シャッターを備えるシャッター眼鏡を装着する。シャッター眼鏡は、表示画面上で左目映像と右目映像が切り換わる周期と同期して左右の液晶シャッターを交互に開閉する。そして、左目映像が表示されるタイミングでは、ユーザの左目の前の液晶シャッターのみが開かれ、右目映像が表示されるタイミングでは、ユーザの右目の前の液晶シャッターのみが開かれる。これにより、ユーザの左目には左映像が視認され、右目には右目映像が視認されることとなり、ユーザは立体映像を視認することができる。
【００１５】
図１に示すような複数の映像をストリーミングする構成では、送信側のエンコーダ１１０，１２０では複数の映像を同じタイミングで同期エンコード処理し、受信側のデコーダ２１０，２２０では同じタイミングで同期デコード処理する。ＩＰネットワーク３００上でジッタが少なく、複数のストリームが到着する遅延時間が少ない状態であれば、同期エンコード処理と同期デコード処理を行うことで、３Ｄデュアルストリームの映像を同期して再生することが可能である。
【００１６】
しかし、複数映像のストリーミングの際にジッタ、遅延、パケットロス等が発生すると、同期デコードすべきタイミングでコンテンツが受信側のデコーダ２１０，２２０に入力されない状態が発生し、左右の再生される映像がフレーム単位でずれてしまう。また一度左右の映像がフレーム単位でずれてしまうと、その後の映像もフレーム単位でずれた状態のままとなり、同期デコードを行うことができなくなる。
【００１７】
以上のように、複数映像のストリーミングを行う場合、パケットロス、ネットワーク３００におけるジッタ、遅延の影響等により、いずれか一方の映像が他方に対して遅延した状態で受信側の装置に到達ししまうことが考えられる。この場合、左映像と右映像のフレームにずれが生じてしまい、所望の立体映像を表示することが困難となる。このため、以下に説明する本実施形態では、フレームにずれが生じた場合は、これを検出し、回復させる処理を行う。以下、詳細に説明する。
【００１８】
２．送信側、受信側の端末構成
図２及び図３は、送信側と受信側の端末の構成をそれぞれ示す模式図である。図２及び図３に示す各構成要素は、ハードウェア（回路）、またはＣＰＵなどの中央演算処理装置と、これを機能させるためのプログラムから構成することができる。この場合に、そのプログラムは、端末が備えるメモリなどの記憶部に格納されることができ、また、ディスク状記憶媒体、ＵＳＢメモリなど外部から挿入される記憶媒体に格納されることができる。図２は、送信側端末１００の構成を示す模式図である。送信側端末１００は、左目映像のエンコーダ１１０、左目映像のネットワークインタフェース１３０、右目映像のエンコーダ１２０、右目映像のネットワークインタフェース１４０、同期エンコード処理部１５０、を備える。
【００１９】
左目映像のエンコーダ１１０と右目映像のエンコーダ１２０は、同期エンコード処理部１５０が発生する同期クロックに基づいて動作し、左右の映像（左目映像及び右目映像）を同期してエンコードする。エンコードされた左右の映像は、ＲＴＰパケットなどにパケット化され、左右のネットワークインターフェース１３０，１４０から受信側端末２００に送信される。例えばエンコードしたデータをＭＰＥＧ２システムに入れる場合において、同期エンコード処理部１５０が発生する同期したクロックに基づきエンコーダ１１０，１２０が動作している場合、同じフレームの映像に関しては同じＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が付与される。
【００２０】
図３は、受信側端末２００の構成を示す模式図である。受信側端末２００は、左目映像のデコーダ２１０、右目映像のデコーダ２２０、左目映像のネットワークインタフェース２５０、左目映像のバッファ２６０、右目映像のネットワークインタフェース２７０、右目映像のバッファ２８０、フレームずれ検知処理部２８２、フレームずれ回復処理部２８４、を備える。また、受信側端末２００は、クロック２９０、ＰＷＭ２９２を備える。
【００２１】
ネットワークインタフェース２５０は、送信側端末１００から送られた左目映像のＲＴＰパケットを受信する。ネットワークインタフェース２７０は、送信側端末１００から送られた右目映像のＲＴＰパケットを受信する。受信した左目映像のＲＴＰパケットはバッファ２６０に送られ、受信した右目映像のＲＴＰパケットはバッファ２８０に送られる。そして、ネットワークインターフェース２５０，２７０から受信したＲＴＰパケットは、バッファ２６０，２８０を経由して同期デコードを行っているデコーダ２１０，２２０に送信される。
【００２２】
発振器２９０は、一定の周期でクロック信号を発生させる。デコーダ２１０，２２０は、発振器２９０が発生するクロック信号に基づいて、左目映像と右目映像の同期デコードを行う。
【００２３】
ここで、ＩＰネットワーク３００でのジッタや遅延がバッファ２６０，２８０で吸収できる程度の大きさであれば、デコーダ２１０，２２０が同期デコードし続けることは可能であるが、バッファ２６０，２８０の許容量を超えるジッタや遅延がある場合は、フレームずれが発生する。
【００２４】
３．トランスポートストリームの構成
図４は、トランスポートストリームの構成を示す模式図である。図４に示すように、映像データ（ビデオ符号化データ）は、ＭＰＥＧ２システムのＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）に分割される。送信側端末１００のエンコーダ１１０，１２０は、映像データの１フレームを複数のＴＳに分割し、先頭のＴＳにＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）を記述することで、受信側端末２００のデコーダ２１０，２２０側がフレームを表示すべきタイミングを通知する。ＰＴＳは、トランスポートストリームのＴＳヘッダに挿入される。また、メディア間の同期をとるためのＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）情報、ＰＡＴ，ＰＭＴ等のプログラム情報などもＴＳパケットに分割される。また、図４に示すように、ＩＰネットワーク３００上でＴＳを送信する際には、ＴＳパケットの前にＲＴＰヘッダとＩＰヘッダを追加して送信する。
【００２５】
なお、放送波などでは、遅延が少なく、ジッタが少なく、ロスがほとんど起きない環境下では、ＳＴＣをＰＣＲのクロックに同期させて、フレームを同期させることができる。しかし、ＩＰネットワーク３００のようにジッタが大きくパケットロスが多い環境下では、ＰＣＲを用いたクロック同期を行うことができない。
【００２６】
図５は、本実施形態のようなＩＰネットワーク３００を用いたシステムでのデコードの仕組みを示す模式図である。ＩＰネットワーク３００では、放送波のようなＰＣＲを用いたクロック同期を行うことはできないので、ＰＣＲの値とは独立してクロックコントロールを行う。受信側端末２００は、ＰＷＭ２９２により発振器（ＶＣＸＯ）２９０を制御し、デコーダ２１０，２２０にクロック信号を入力する。デコーダ２１０，２２０は、入力されたクロック信号に基づいてＳＴＣ（システムクロック）をカウントアップし、ネットワークインターフェース２５０，２７０から受信したＴＳのＰＴＳに基づいてフレームの表示を行う。このときのＰＷＭのコントロール方法は、バッファサイズの遷移などの方法で行うことが可能である。
【００２７】
４．フレーム表示の例
図６は、ＳＴＣとＰＴＳの値に基づいてフレーム表示を行う様子を示す模式図である。図６において、Ｐ１，Ｐ２，Ｐ３・・・は、１フレームのＴＳパケットを示している。図６に示す構成では、ＳＴＣとＰＴＳが厳密な同期を行うことはできないので、ＰＴＳとＳＴＣは絶対時間では一致しない。そこでフレームを表示は、ＳＴＣの差分値とＰＴＳの差分値が一致した時に行う。図６に示すように、フレームを表示すべきタイミングＳＴＣ１，
ＳＴＣ２においては、ＳＴＣ１，ＳＴＣ２のタイミングよりも前に到着したＴＳパケットで構成されるＰ１，Ｐ２のフレームを表示している。例えば、３０フレーム／ｓのフレームレートで表示を行う際にＳＴＣ１が０［ｓ］のタイミングでＰＴＳが２０ｍｓの映像フレームを表示したとすると、次のフレームを表示するＳＴＣ２は３３ｍｓとなるので、ＰＴＳの値が５５ｍｓと記述されているＴＳパケットで構成されるフレームをＳＴＣ２のタイミングで表示する。
【００２８】
図７は、ジッタが大きい場合にフレーム表示を行う様子を示す模式図である。ＰＴＳが記述されたＴＳパケットの到着タイミングがジッタにより遅れてしまうと、フレームを表示すべきタイミングで該当のフレームが表示できなくなる。図７に示す例では、ＳＴＣ３のタイミングでＰ３のフレームが到着していないため、ＳＴＣ３のタイミングでＰ３のフレームを表示することができない。次のＳＴＣ４のタイミングでどのフレームを表示するかはデコーダの仕様次第ではあるが、ＩＰネットワーク３００ではルーティング変更によりパケット到着が定常的に遅くなる可能性があることを考慮すると、バッファに蓄積されているＰ３のフレームをＳＴＣ４のタイミングで表示し、その後は新たなＰＴＳとＳＴＣの差分値に基づいてフレーム表示を行うことになる。
【００２９】
図７に示すようなジッタが発生した場合においても、２Ｄ映像の場合は、ストリーミングする映像データが１つであるため、複数映像におけるフレームずれの問題は生じない。しかしながら、複数の映像データをストリーミングする場合、ある映像データが他のデータに対して遅れてしまう問題が発生する。例えば、３Ｄデュアルストリーミングでフレーム同期を行う場合、一方のストリーミングデータのみにジッタが発生すると、一方の映像に対して他方の映像が遅れて表示されてしまう。
【００３０】
図８は、３Ｄの映像データでフレームずれが発生した場合を示す模式図である。左映像のＰ３のフレームのジッタが大きい場合、Ｐ３のフレームを表示すべきタイミング（ＳＴＣ３）で、左映像のＰ３のフレームを表示することができない。ＩＰネットワーク３００に対応したデコーダを用いている場合、次のＳＴＣ４のタイミングで右映像はＰ４のフレームを表示するのに対して、左映像はＰ３のフレームを表示する。この後のフレームも同様に、ＳＴＣの差分とＰＴＳの差分に基づいて表示することから、常にフレームずれの状態が継続してしまう。
【００３１】
このため、本実施形態では、フレームずれ検知処理部２８２が、左目映像と右目映像のデコーダ２１０，２２０のデータからフレームずれの発生を検知する。そして、フレームずれ検知処理部２８２は、左目映像と右目映像にフレームずれが発生している場合は、その旨をフレームずれ回復処理部２８４に通知する。フレームずれ回復処理部２８４は、フレームずれが生じている旨の通知を受けると、左目映像と右目映像のバッファ２６０，２８０に対してフレームずれの回復処理を行う。
【００３２】
５．フレームずれを検知する処理
図９は、フレームずれを検知する処理を示すフローチャートである。図９に示す処理は、フレームずれ検知処理部２８２が主として行う。先ず、ステップＳ１０では、フレーム更新タイミングが到来したか否かを判定する。フレーム更新タイミングは、エンコードした映像データのフレームレートに応じて一定の値に定められており、図６〜図８等に示したＳＴＣ１，ＳＴＣ２，ＳＴＣ３，・・・に対応する。例えば、３０ｐのフレームレートであれば３３．３ｍｓ毎にフレームが更新される。ステップＳ１０において、フレーム更新タイミングが到来した場合はステップＳ１２へ進む。一方、ステップＳ１０において、フレーム更新タイミングが到来していない場合は、ステップＳ１０で待機する。
【００３３】
ステップＳ１２に進んだ場合、フレーム更新タイミングにおいて、フレームずれ検知処理部２８２は、２つのデコーダ２１０，２２０から、デコーダ２１０，２２０が表示部２３０に現在表示している左目映像と右目映像のフレームのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）を取得する。次のステップＳ１４では、ステップＳ１２で取得した２つのＰＴＳを比較する。
【００３４】
ステップＳ１４での比較の結果、２つのＰＴＳが異なる場合は、ステップＳ１６へ進む。この場合、フレームずれ検知処理部２８２は、左右の映像のフレームがずれていると判定する。例えば、図８のＳＴＣ４では、左目映像がＰ４のフレームであり、右目映像がＰ３のフレームであるため、左目映像と右目映像のフレームのＰＴＳが異なり、左右の映像のフレームがずれていると判定する。
【００３５】
一方、ステップＳ１４での比較の結果、２つのＰＴＳが等しい場合は、ステップＳ１０へ戻り、以降の処理を再度行う。
【００３６】
６．フレームずれを回復する処理
図１０は、フレームずれが発生した場合に、これを回復させる処理を示すフローチャットである。図１０に示す処理は、フレームずれ回復処理部２８４が主として行う。図８で説明したように、フレームずれが発生した後に映像をデコーダ２１０，２２０にそのまま送信し続けると、デコーダ２１０，２２０で再生されるフレームが互いにずれた状態が継続されてしまう。このため、フレームずれ回復処理部２８４は、フレームずれ検知処理部２８２により左右の映像のフレームがずれていると判定された場合は、バッファ２６０，２８０に対して映像データを廃棄し続けるように指示する（ステップＳ２０）。映像データを廃棄する方法としては、例えば映像のコンテンツデータがＴＴＳの場合、ＴＴＳパケットのタイムスタンプとシステムクロックを比較して、クロックと同じＴＴＳパケットを廃棄する方法で行うことができる。また、バッファ２６０，２８０内部のデータをすべて廃棄するという方法を用いてもよい。
【００３７】
次に、ステップＳ２２では、フレーム更新タイミングが到来したか否かを判定する。フレーム更新タイミングが到来した場合は、ステップＳ２４へ進む。一方、フレーム更新タイミングが到来していない場合は、ステップＳ２２で待機する。
【００３８】
ステップＳ２４では、フレーム更新タイミングにおいて、２つのデコーダ２１０，２２０の双方で映像が更新されていないか、を判定する。２つのデコーダ２１０，２２０のいずれか一方で映像が更新されている場合は、そのデコーダのバッファ（デコーダバッファ）の中に映像データが存在しているため、ステップＳ２２へ進み、次のフレーム更新タイミングまで待機する。一方、２つのデコーダ２１０，２２０の双方で映像フレームが更新されていない場合は、デコーダバッファが空になっているので、ステップＳ２６へ進み、再度２つのバッファ２６０，２８０からデコーダ２１０，２２０への映像の送信を再開する。
【００３９】
図１０の処理によれば、２つのデコーダ２１０，２２０の双方で映像フレームが更新されていない状態となるまでは、バッファ２６０，２８０に蓄積された映像データの廃棄が継続される。従って、ジッタ等によるフレームずれが生じた場合は、フレームずれが生じた映像データを廃棄することができる。以上のように、フレームずれが生じている場合は、バッファ２６０，２８０に対して回復（廃棄）処理を行うことで、フレームずれを解消することができる。
【００４０】
バッファに蓄積された映像データが廃棄され続けると、デコーダ２１０，２２０に新たに映像データが入力されない状態となり、２つのデコーダ２１０，２２０の双方において、デコードされてデコーダバッファから出力される映像フレームが更新されない状態となる。そして、デコーダ２１０，２２０の双方で映像フレームが更新されていない状態になると、バッファ２６０，２８０からデコーダ２１０，２２０への映像の送信が再開される。これにより、バッファ２６０，２８０からデコーダ２１０，２２０へ同期した映像フレームの送信を再開することができる。
【００４１】
図１１は、本実施形態の手法により、左右のフレームがずれた状態から回復する様子を示す模式図である。図１１では、左映像のフレームＰ３の到着がジッタ等により遅延した場合を示している。ＳＴＣ４のタイミングでは、右映像についてはフレームＰ４が表示されるが、左映像はフレームＰ３が表示される。このため、ＳＴＣ４のタイミングでは、デコーダ２１０，２２０のそれぞれで取得されるＰＴＣの値が異なり、フレームずれ検知処理部２８２により左右のフレームがずれていることが検知される。
【００４２】
フレームずれ回復処理部２８４は、ＳＴＣ４のタイミングでバッファ２６０，２８０に蓄積されている映像フレームを廃棄する。このため、ＳＴＣ４以降に到着したフレームＰ５は、左右のバッファ２６０，２８０において廃棄される。次のフレーム表示タイミングＳＴＣ５において、デコーダ２１０，２２０の双方で左右映像のフレームの更新が行われていない場合は、バッファ２６０，２８０に到着したパケットのデコーダ２１０，２２０への送信を再開する。これにより、図８の仕組みに基づいて、ＰＴＳの差分情報がクリアされ、次に左右で再び同期されたフレームが表示される。
【００４３】
以上説明したように本実施形態によれば、フレーム単位で同期をとる必要がある複数ストリームの映像を、別のＩＰネットワーク経由で配信しても、受信側で同期を取って再生することが可能になる。また、受信側でフレーム単位の同期がずれた場合に、自動で検知することが可能となり、同期ずれを自動で回復することが可能になる。
【００４４】
なお、上述した実施形態では、複数のストリーミングデータとして３Ｄの左右映像を例示したが、例えば４Ｋの映像を１９２０×１０８０ピクセルの４つの映像に分割し、各々を別のネットワークを介して送信する場合などにも利用することができ、分割したデータの同期を確保することが可能である。
【００４５】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００４６】
なお、本技術は以下のような構成も取ることができる。
（１）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、
前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、
を備える、情報処理装置。
【００４７】
（２）前記複数の映像データストリームのそれぞれをデコードするデコーダを備え、
前記ずれ検出部は、前記デコーダでデコードされた前記複数の映像データストリームのそれぞれのＰＴＣを映像のフレーム毎に比較して、前記複数の映像データストリームの時間的なずれを検出する、前記（１）に記載の情報処理装置。
【００４８】
（３）前記複数の映像データストリームのデータをそれぞれ蓄積するバッファを備え、
前記ずれ回復処理部は、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、前記バッファに蓄積された前記複数の映像データストリームのデータを消去する、前記（１）に記載の情報処理装置。
【００４９】
（４）前記ずれ回復処理部は、前記デコーダ内に前記複数の映像データストリームのデータが存在しなくなった時点で、前記バッファに蓄積された前記複数の映像データストリームのデータ消去を停止する、前記（３）に記載の情報処理装置。
【００５０】
（５）前記複数の映像データストリームは、左目映像の映像データストリームと右目映像の映像データストリームとから構成される、前記（１）に記載の情報処理装置。
【００５１】
（６）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信すること、
前記複数の映像データストリームの時間的なずれを検出することと、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うことと、
を備える、方法。
【００５２】
（７）時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する手段、
前記複数の映像データストリームの時間的なずれを検出する手段、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行う手段、
をコンピュータに実行させるためのプログラム。
【符号の説明】
【００５３】
２００ 受信側端末
２１０，２２０ デコーダ
２５０，２７０ ネットワークインターフェース
２６０，２８０ バッファ
２８２ フレームずれ検知処理部
２８４ フレームずれ回復処理部
【特許請求の範囲】
【請求項１】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、
前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、
を備える、情報処理装置。
【請求項２】
前記複数の映像データストリームのそれぞれをデコードするデコーダを備え、
前記ずれ検出部は、前記デコーダでデコードされた前記複数の映像データストリームのそれぞれのＰＴＣを映像のフレーム毎に比較して、前記複数の映像データストリームの時間的なずれを検出する、請求項１に記載の情報処理装置。
【請求項３】
前記複数の映像データストリームのデータをそれぞれ蓄積するバッファを備え、
前記ずれ回復処理部は、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、前記バッファに蓄積された前記複数の映像データストリームのデータを消去する、請求項１に記載の情報処理装置。
【請求項４】
前記ずれ回復処理部は、前記デコーダ内に前記複数の映像データストリームのデータが存在しなくなった時点で、前記バッファに蓄積された前記複数の映像データストリームのデータ消去を停止する、請求項３に記載の情報処理装置。
【請求項５】
前記複数の映像データストリームは、左目映像の映像データストリームと右目映像の映像データストリームとから構成される、請求項１に記載の情報処理装置。
【請求項６】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信すること、
前記複数の映像データストリームの時間的なずれを検出することと、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うことと、
を備える、情報処理方法。
【請求項７】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する手段、
前記複数の映像データストリームの時間的なずれを検出する手段、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行う手段、
をコンピュータに実行させるためのプログラム。
【請求項１】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する受信部と、
前記複数の映像データストリームの時間的なずれを検出するずれ検出部と、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うずれ回復処理部と、
を備える、情報処理装置。
【請求項２】
前記複数の映像データストリームのそれぞれをデコードするデコーダを備え、
前記ずれ検出部は、前記デコーダでデコードされた前記複数の映像データストリームのそれぞれのＰＴＣを映像のフレーム毎に比較して、前記複数の映像データストリームの時間的なずれを検出する、請求項１に記載の情報処理装置。
【請求項３】
前記複数の映像データストリームのデータをそれぞれ蓄積するバッファを備え、
前記ずれ回復処理部は、前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、前記バッファに蓄積された前記複数の映像データストリームのデータを消去する、請求項１に記載の情報処理装置。
【請求項４】
前記ずれ回復処理部は、前記デコーダ内に前記複数の映像データストリームのデータが存在しなくなった時点で、前記バッファに蓄積された前記複数の映像データストリームのデータ消去を停止する、請求項３に記載の情報処理装置。
【請求項５】
前記複数の映像データストリームは、左目映像の映像データストリームと右目映像の映像データストリームとから構成される、請求項１に記載の情報処理装置。
【請求項６】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信すること、
前記複数の映像データストリームの時間的なずれを検出することと、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行うことと、
を備える、情報処理方法。
【請求項７】
時間的に同期して送信された異なる複数の映像データストリームをそれぞれ受信する手段、
前記複数の映像データストリームの時間的なずれを検出する手段、
前記ずれ検出部で前記複数の映像データストリームの時間的なずれが検出された場合に、ずれを回復する処理を行う手段、
をコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−２５７０５１（Ｐ２０１２−２５７０５１Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１１−１２８４７８（Ｐ２０１１−１２８４７８）
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]