JP2009044436A

JP2009044436A - 映像処理装置及び映像処理システム

Info

Publication number: JP2009044436A
Application number: JP2007206955A
Authority: JP
Inventors: Akiyoshi Kato; 昭慶加藤
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-08-08
Filing date: 2007-08-08
Publication date: 2009-02-26
Also published as: US20090251608A1; WO2009020133A1

Abstract

【課題】システムに接続された機器がユーザの行なった指示とは異なる動作を行なう場合に、ユーザがそれを認識することのできる映像処理装置及び映像処理システムを提供する。
【解決手段】他の映像処理装置から通信路を介して第１速度で映像音声信号を受信し、他の映像処理装置と通信路を介して第１速度より低速な第２速度で制御信号の通信を行う通信部２１，２２と、通信部の行なう制御信号の通信処理であって、所定コマンドに対する処理計画の送信を要求する特定信号を他の映像処理装置に送信し、他の映像処理装置から所定コマンドに対する処理計画を示すある特定信号を受信し、これにより、所定コマンドの実行を要求された際に、ある特定信号が示す所定コマンドに対する処理計画を表示する画像を生成する処理予測部２４−１と、映像音声信号に応じた画像と所定コマンドに対する処理計画を表示する画像を画面上に表示する表示部２５をもつ映像処理装置。
【選択図】図３

Description

この発明は、ＨＤＭＩ（High-Definition Multimedia Interface）規格等による通信機能をもった映像処理装置であって、特定のコマンドの処理計画情報を扱う映像処理装置及び映像処理システムに関する。

ＨＤＭＩ（High-Definition Multimedia Interface）規格は、映像音声信号と制御信号とについてそれぞれ異なる速度で複数の映像処理装置の間で通信を行なう通信規格として知られており、利用されている。このような通信規格等を用いることで映像処理システムが構築することができ、例えば、表示機能をもったシンク機器からソースを供給する映像処理装置であるソース機器の電源のオン・オフ操作を行なうことも可能になる。

しかし、一般に映像処理システムにおいては、例えば、ハードディスクレコーダであれば、電源オフのコマンドを受けた際に録画中であれば電源オフを行なわず録画を継続する等の処理を行なう場合がある等、必ずしも命令通りに動作しないことがある。ユーザはこの結果、システムの故障が起きた等の誤解をすることがある。

特許文献１は、再生指令に応じて記録映像を再生中に、再生映像が放送番組に追いつきそうになった時、そのまま命令どおり再生を続けるか、放送されている放送番組の方の再生を行なうかをユーザに問い合わせる技術が開示されている。
特開２００１−１９５８０７号公報

しかし、特許文献１の従来技術は、ユーザから命令を受けた時に、その命令に応じてどのような選択肢が存在するかを知ることができない、例えば、ＨＤＭＩ規格で接続された映像処理システムにおいて、どのような方法でユーザに問合せ処理を行なうかが分からないという課題がある。

又、一般の映像処理システムにおいて、シンク機器からソース機器の電源をオフするべくコマンドを送信しても、ソース機器が映像音声信号等を再生中であるため再生を停止しないので、見かけ上、ユーザの操作が無視されたかのように見え、システムが故障しているかのようにユーザに誤解させてしまう可能性がある。

本発明は、システムに接続された機器がユーザの行なった指示とは異なる動作を行なう場合に、ユーザがそれを認識することのできる映像処理装置及び映像処理システムを提供することを目的とする。

課題を解決するための一実施形態は、
他の映像処理装置（１０）から通信路を介して第１速度で映像音声信号を受信し、前記他の映像処理装置（１０）と前記通信路を介して前記第１速度より低速な第２速度で制御信号の通信を行う通信部（２１，２２）と、
前記通信部の行なう前記制御信号の通信処理であって、所定コマンドに対する処理計画の送信を要求する要求信号（図９）を前記他の映像処理装置に送信し、前記他の映像処理装置から前記所定コマンドに対する処理計画を示すメッセージ信号（図１０，図１１，図１２）を受信し、これにより、前記所定コマンドの実行を要求された際に、前記メッセージ信号が示す所定コマンドに対する処理計画を表示する画像を生成する処理予測部（２４−１）と、
前記通信部を介して受信した前記映像音声信号に応じた画像を表示すると共に、前記処理予測部が生成した前記所定コマンドに対する処理計画を表示する画像を画面上に表示する表示部（２５）と、を具備することを特徴とする映像処理装置。

ＨＤＭＩ規格等で接続された映像処理システムにて、シンク機器からソース機器の電源をオフする際に、電源オフに対する処理計画を事前にソース機器から収集し、ユーザから電源オフが命じられると、この収集情報に基づき、メッセージを表示する。

以下、この発明の実施の形態について図面を参照して詳細に説明する。

＜本発明に係る一実施形態である映像処理システムの構成の一例＞
初めに、本発明に係る一実施形態である映像処理システムの構成の一例を図面を用いて説明する。図１は、本発明の一実施形態に係るシンク機器の映像処理装置とこれに接続されるソース機器の映像処理装置をもつ映像処理システムの一例を示すブロック図である。図２は、本発明の一実施形態に係るソース機器である映像処理装置の構成の一例を示すブロック図である。図３は、本発明の一実施形態に係るシンク機器である映像処理装置の構成の一例を示すブロック図である。

本発明に係る一実施形態である映像処理システム１は、図１に示すように、複数のソース機器１０，１０’と、ＨＤＭＩケーブル１０１で接続されたシンク機器２０を有している。なお、ＨＤＭＩケーブル１０１は、映像音声信号の送受信線１０１−１と、アドレス／データの送受信線１０１−２と、コマンドの送受信線１０１−３をもっており、一例として、映像音声信号の送受信線１０１−１やアドレス／データの送受信線１０１−２は、コマンドの送受信線１０１−３より高速に通信を行なう。

シンク機器２０は、図３に示すように、ソース機器１０からの映像音声信号を表示し出力するための機器であり、具体的にはテレビ等である。ソース機器１０は、映像音声信号をシンク機器２０へ供給するための機器であり、具体的には、ＨＤＤＶＤレコーダ等である。

ソース機器１０は、図２に示すように、映像生成部１３及び中央演算装置である制御部１４を持ち、制御部１４は、後述する処理予測部１４−１を含むと共に、全体の動作の制御を行う。更に、ソース機器１０は、映像送信部１１を有しており、映像送信部１１は、シンク機器２０へ映像音声信号を送信したり、アドレス／データを送受信したりする。又、コマンド送受信部１２は、シンク機器２０を制御するためのコマンド（制御信号）を送信したり、シンク機器２０側からのコマンド（制御信号）を受信したりする部分である。

ソース機器１０を制御するためのメッセージ画面も、例えばＨＴＭＬやＸＭＬ等の形式で、コマンド送受信部を経由した映像信号としてシンク機器２０へ送られる。

シンク機器２０は、図３に示すように、映像処理部２３及び中央演算装置である制御部２４を持ち、制御部２４は、後述する処理予測部２４−１を含むと共に、全体の動作の制御を行う。更に、シンク機器２０は、映像受信部２１を有しており、映像受信部２１は、ソース機器１０からの映像音声信号を受信したり、アドレス／データを送受信したりする。又、コマンド送受信部２２は、ソース機器１０を制御するためのコマンド（制御信号）を送信したり、シンク機器２０側へのコマンド（制御信号）を受信したりする部分である。

具体的には、ＨＤＭＩ（High-Definition Multimedia Interface）や、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等である。ＨＤＭＩの場合は、制御コマンドの送受信にＣＥＣ（Consumer Electronics Control）ラインを用いる。

表示部２５は、機器制御のためのメッセージ画面やソース機器１０からの映像を表示する画面であり、具体的には、液晶パネル等である。

・ＨＤＭＩ端子
図４は、本発明の一実施形態に係る映像処理装置が有しているＨＤＭＩ端子の信号名を示す説明図である。

通信がＨＤＭＩでなされている場合は、ＨＤＭＩ端子は、図４に示すようなコネクタピン配列を有している。特に１３ピンのＣＥＣ信号によって、ＨＤＭＩ−ＣＥＣプロトコルに準拠して定義されたコマンドを送受信することで、相手機器の制御が可能となる。

＜本発明の一実施形態である処理予測方法の一例＞
次に、上述した映像処理システムにおける処理予測方法の一例をフローチャートを用いて詳細に説明する。

なお、以下の図５乃至図８のフローチャートの各ステップは、回路ブロックに置き換えることができ、従って、各フローチャートのステップは、全てブロックに定義しなおすことが可能である。

（本発明の一実施形態である処理予測方法が実施されない場合の不具合）
初めに、本発明の一実施形態である処理予測方法が実施されない場合の不具合を説明する。図５は、本発明が実施されない場合のシステム電源オフの際の機器制御動作の一例を示すフローチャートである。

すなわち、シンク機器２０は、図５のフローチャートに示すように、例えば、ユーザの『システム電源オフ』操作により、ＣＥＣ信号線を介して『Standbyコマンド』をブロードキャストする。その後、シンク機器２０は、シンク機器２０の電源をオフにする（ステップＳ１）。

しかし、シンク機器２０及びソース機器１０は、『Standbyコマンド』に対応する処理を行うが、ソース機器１０は、録画中なので録画終了後に電源をオフするがすぐには電源をオフしない(ステップＳ２)。又、同様に、第２のソース機器１０’は、同様に、再生中なのでユーザの操作を待つために電源オフは行なわない (ステップＳ３)。

この結果、第１のソース機器１０及び第２のソース機器１０’は、電源がオフにならないままシンク機器２０の電源だけオフとなってしまうため、ユーザの意図が反映されない処理であったと言える。

このように、本発明が実施されない上記の実施形態では、『システム電源オフ』という操作を受けても、単に各機器に電源オフ操作を通知することしかできず、通知を受けた機器がその後どのように動作する計画であるかをユーザに返答するすべがない。

従って、実際にコマンドを発行して機器が『システム電源オフ』動作に入るまで、ユーザは、機器の動作状況を確認できないという不具合が生じることとなる。

上述した本発明が実施されない実施形態では、録画中の機器や映像再生中などのユーザ操作を要求する機器の電源はオフとならない。従って、ユーザは、電源オフにならなかった機器の状態を確認・操作するために、再びシンク機器２０の電源を入れて複数のソース機器１０，１０’を選択して操作しなければならない。

このように、本発明が実施されない上記の実施形態では、機器操作に手間がかかるばかりでなく、電源オフしなかった機器の存在を失念したために、ユーザの希望する動作、例えば、レコーダにおいて予約録画等を失敗するといった不具合がある。

（本発明の第1の実施形態である処理予測方法の一例）
本発明に係る一実施形態である処理予測方法は、このような不具合の解消を課題とするものであり、事前に通信回線を介して、所定コマンドに対する処理計画の情報を収集し、これに基づくメッセージを表示する。これにより、ユーザに対する誤解や誤操作を回避することができる。図６は、本発明の第１の実施形態であるシンク機器及びソース機器の処理予測方法の一例を示すフローチャートである。

初めに、本発明に係る一実施形態であるシンク機器２０の制御部２４及び処理予測部２４−１は、図６のフローチャートに示すように、以下のような処理予測方法を行なう。すなわち、初めに、シンク機器２０には、第１のソース機器１０及び第２のソース機器１０’の２台が接続されているものとする。

まず、シンク機器２０の制御部２４及び処理予測部２４−１は、第１のソース機器１０に対して、「仮に『システム電源オフのメッセージ』を受信したときにソース機器１０がどのような電源管理を行う計画であるか」を問い合わせる(ステップＳ１１)。

それに対して、第１のソース機器１０の制御部１４及び処理予測部１４−１は、仮の『システム電源オフのメッセージ』に対する電源管理計画をシンク機器２０に図６に示すようなコード表のコードで返答し、実際には『システム電源オフ』動作には入らない。ここでは、「録画終了後に電源オフする(０x０１)」を返答したものとする(ステップＳ１２）。

同様に、シンク機器２０の制御部２４及び処理予測部２４−１は、第２のソース機器１０’に対して、同じ問い合わせを行う(ステップＳ１３)。それに対して、第２のソース機器１０’の制御部１４及び処理予測部１４−１は、電源管理計画をシンク機器２０にコードで返答するが、実際には『システム電源オフ』動作には入らない。ここでは、「電源オンを継続する(０x０２)」を返答したものする(ステップＳ１４)。

次に、シンク機器２０の制御部２４及び処理予測部２４−１が、ユーザからの『システム電源オフ』操作を検出すると、第１のソース機器１０及び第２のソース機器１０’の返答であるコードに基づいて、『システム電源オフ』操作に対して疑義のあるソース機器１０のメッセージ画像Ｍ１を生成し構成してユーザに表示し、ユーザの選択を促す(ステップＳ２５)。このメッセージ画像Ｍ１では、第１のソース機器１０が、録画終了後のオフする予定であること、第２のソース機器１０’が電源オンを継続する予定であることが示されている。このメッセージ画像Ｍ１では、同時に、現在、操作が可能な選択枝として、『システム電源オフ』操作についてオン（有効）とするか、例えば、『システム電源オフ』操作したにもかかわらず『電源オン継続』するという第２ソース機器３０’をモニタするか、また、『システム電源オフ』操作をキャンセルするかの選択枝を併せて表示する。

ユーザがリモコンなどのインタフェースを介してメッセージ画像Ｍ１を操作すると、シンク機器２０の制御部２４及び処理予測部２４−１は、ユーザの操作に対応する操作コマンドをＣＥＣ制御線経由でソース機器１０，１０’に送信して、ソース機器１０，１０’を制御する(ステップＳ１６)。シンク機器２０からの操作コマンドに対する各ソース機器１０，１０’の応答を確認し(ステップＳ１７)、準備ができたらシンク機器２０の電源をオフする(ステップＳ１８)。

なお、これらの実施形態では、ステップＳ１１乃至Ｓ１４を、ユーザの『システム電源オフ』操作前に実施したが、ユーザの『システム電源オフ』操作のあとに実施することも好適である。

このように、上述した本発明の一実施形態である処理予測方法の一例によれば、ソース機器１０の都合でユーザの操作に従えないケースがあっても、シンク機器２０の電源を落とすことなく、即座にソース機器１０，１０’の状況をユーザに提示することが可能となる。すなわち、ユーザは、メッセージ画像Ｍ１により現在の状況を知りえるため、ソース機器１０，１０’が電源オフにできない理由を確認するために、一旦電源が落とされてしまったシンク機器２０の電源を再投入するといった手間が必要なくなる。又、電源オフにできないソース機器を見落とすことがないため、ユーザが故障と誤解することがなく、ソース機器の電源オンが継続されたために予約録画に失敗する等の操作ミスをなくすことが可能となり、ユーザの利便性を向上させることができる。

（本発明の第２の実施形態である処理予測方法の一例：メッセージ画像）
次に、本発明の第２の実施形態である処理予測方法の一例を図７を用いて説明する。図７は、本発明の第２の実施形態であるシンク機器及びソース機器の処理予測方法の一例を示すフローチャートである。

ここでは、１台のソース機器１０の動作例を用いて説明しているが、ソース機器１０が複数ある場合は、それぞれに対して同様の操作を行うものとする。

まず、シンク機器２０の制御部２４及び処理予測部２４−１は、第１のソース機器１０に対して、「仮に『システム電源オフのメッセージ』を受信したときにソース機器１０がどのような電源管理を行う計画であるか」を問い合わせる(ステップＳ２１)。

それに対して、第１のソース機器１０の制御部１４及び処理予測部１４−１は、仮の『システム電源オフのメッセージ』に対する電源管理計画をシンク機器２０に図７で示すようなコードで返答するが、実際には『システム電源オフ』動作には入らない。ここでは、「録画終了後に電源オフする(０ｘ０１)」を返答したものとする(ステップＳ２２）。ここで、図７が示すコード表では、選択肢として、『メッセージ画像あり：３』を更に追加している。

次に、シンク機器２０の制御部２４及び処理予測部２４−１が、ユーザからの『システム電源オフ』操作を検出すると(ステップＳ２３)、シンク機器２０の制御部２４及び処理予測部２４−１は、第１のソース機器１０の返答であるコードに基づいて、『システム電源オフ』操作に対して疑義のあるソース機器１０のメッセージ画像Ｍ２を生成し構成してユーザに表示し、ユーザの選択を促す。すなわち、『切替え』は、第１のソース機器１０からのメッセージ画像Ｍ３に切り替えることを意味する。また、『キャンセル』は、先に行なった『システム電源オフ』操作をキャンセルすることになる。

ユーザは、リモコンなどのインタフェースを介してメッセージ画像Ｍ２を操作する。ここでは『切替え』を選択したものとする。シンク機器２０の制御部２４及び処理予測部２４−１は、ＣＥＣ制御線経由でソース機器１０にメッセージ画像Ｍ３の出力を要求する(ステップＳ２４)。ソース機器１０は、ユーザの操作を促すメッセージ画像Ｍ３を映像ストリームとしてシンク機器２０に送出する(ステップＳ２５)。

シンク機器２０の制御部２４及び処理予測部２４−１は、入力信号の選択をソース機器１０に切替えて、ソース機器１０からのメッセージ画像Ｍ３を表示する(ステップＳ２６)。

これに対して、ユーザは、シンク機器２０のリモコンなどのインタフェースを介して、ソース機器１０を操作し、例えば、録画予約操作をキャンセルする操作を行なう (ステップＳ２７)。すなわち、この場合は、ユーザはハードディスクレコーダの録画予約操作の途中で作業を止めてしまった場合と予想できる。ユーザがこの録画予約操作はキャンセルしてもよいと思えば『はい』を選べば、録画予約操作の途中の操作情報等を保存することなく（又は保存して）、第１のソース機器１０であるハードディスクレコーダ等の録画予約画面等をキャンセルして、第１のソース機器１０の電源をオフすることができる (ステップＳ２８)。更に、シンク機器２０の制御部２４及び処理予測部２４−１は、ソース機器１０からの応答を確認し、準備ができたら、今度はシンク機器２０の電源をオフにする(ステップＳ２９)。

なお、この実施形態では、処理計画の図６の処理計画のメッセージ画面Ｍ１等は表示していないが、表示することも好適である。

また、実施形態ではステップＳ２１乃至Ｓ２２を、ユーザの『システム電源オフ』操作の前に実施したが、ユーザの『システム電源オフ』操作のあとに実施してもよい。

又、上述した実施形態では、ステップＳ２４のシンク機器２０の入力信号の選択をシンク機器２０自身が切り替えているが、ソース機器１０からの入力切替要求コマンドによって切り替えることも好適である。

以上、説明したように、図７のフローチャートの実施形態では、図６のフローチャートの実施形態の効果に加えて、ソース機器１０からのメッセージ画像Ｍ２，Ｍ３により、ユーザに対してより詳細な情報を提示し、より利便性の高い操作を行わせることが可能となる。

（本発明の第３の実施形態である処理予測方法の一例：ｈｔｍｌ形式、ＸＭＬ形式）
次に、本発明の第３の実施形態である処理予測方法の一例を図８を用いて説明する。図８は、本発明の第３の実施形態であるシンク機器及びソース機器の処理予測方法の一例を示すフローチャートである。この第３の実施形態では、処理計画のメッセージ画像をｈｔｍｌやＸＭＬを用いて転送しているので、処理予測情報を先に取得し、その後、この処理計画が更新されたかどうかを問い、更新されていれば、最新の処理計画のメッセージ画像を取得するものである。

まず、シンク機器２０の制御部２４及び処理予測部２４−１は、第１のソース機器１０に対して、「仮に『システム電源オフのメッセージ』を受信したときにソース機器１０がどのような電源管理を行う計画であるか」の情報が更新されているかどうかを問い合わせる (ステップＳ３１)。

それに対して、ソース機器１０の制御部１４及び処理予測部１４−１は、仮のメッセージに対する処理計画の更新状況を図８に示すようなコード表のコードでシンク機器２０に返答する(ステップＳ３２)。ここでは、「ｈｔｍｌメッセージ画像の更新あり(０x０１)」を返答したものとする。

次に、シンク機器２０の制御部２４及び処理予測部２４−１は、ソース機器１０に対して更新された処理計画の送出を要求する(ステップＳ３３)。

これに対して、ソース機器１０の制御部１４及び処理予測部１４−１は、仮のメッセージに対する更新された処理計画を応答メッセージとしてＣＥＣ信号線経由のｈｔｍｌ形式で送出する(ステップＳ３４)。

シンク機器２０の制御部２４及び処理予測部２４−１は、処理計画が正しく受信されたことを確認して、処理計画の受信完了をソース機器１０に通知する(ステップＳ３５)。

次に、ユーザからの操作が発生すると(ステップＳ３６)、シンク機器２０の制御部２４及び処理予測部２４−１は、再び仮のメッセージに対する処理計画の更新状況をソース機器１０に問い合わせる(ステップＳ３７)。

それに対して、ソース機器１０の制御部１４及び処理予測部１４−１は、仮のメッセージに対する処理計画の更新状況をシンク機器２０に返答する(ステップＳ３８)。

ここでソース機器１０の処理計画更新情報があれば、シンク機器２０はステップＳ３３乃至ステップＳ３５を繰り返して処理計画を取得する。

ここでは「更新なし(０x００)」だったので新たに取得は行なわない。シンク機器２０の制御部２４及び処理予測部２４−１は、取得済みの処理計画を示すメッセージ画像Ｍ４を表示するべく画像形成を行い、この画面に対するユーザの選択を促す。ここでは取得したｈｔｍｌデータを、シンク機器２０が有するブラウザ機能で表示できるように画像形成を行なうものとする。

ユーザは、ブラウザ画面であるメッセージ画像Ｍ４からソース機器１０を操作し、シンク機器２０の制御部２４及び処理予測部２４−１は、操作内容を操作信号としてソース機器１０に送信する(ステップＳ３９)。ここでは、操作メッセージをＣＥＣ信号線経由でＸＭＬ形式で送出する例を示している。

なお、ここでは更新された処理計画のメッセージをｈｔｍｌ形式のデータとして説明したが、ＸＭＬ形式であってもよく、他のデータ形式であることも好適である。又、ユーザの操作信号の送信を、ＸＭＬ形式のデータとして説明したが、ｈｔｍｌ形式のデータであってもよく、他の機器制御メッセージであっても良い。

又、応答メッセージ及び操作メッセージの送出に使用する通信路については、図２の１３ピンのＣＥＣが示すＣＥＣ制御線で説明したが、図２の１５ピンのＳＣＬ及び１６ピンのＳＤＡが示すアドレス／データ制御線、すなわち、ＨＤＭＩ規格のＤＤＣ（Ｉ２ＣＢｕｓ）信号線を利用することも好適である。

又、ソース機器１０の制御部１４及び処理予測部１４−１が返答する仮のメッセージに対する処理計画の更新状況については、シンク機器２０からの問い合わせがなくても、処理計画が更新されるたびに通知することも好適である。

以上、第３の実施形態では、返答メッセージにｈｔｍｌを使用し、表示にブラウザを使うことで、システムとして非常に軽い処理でより多くの情報をユーザに提供可能となる。又、機器制御データとしてｈｔｍｌ及びＸＭＬを使用することで、より詳細で柔軟な機器操作が可能となり、機器制御機能の拡張性に優れている。

又、ユーザ操作の前に予め応答メッセージを取得しているため、ユーザの操作に対して即座に応答メッセージを表示可能であり操作性が良くなる。

＜本発明の一実施形態である映像処理システムで使用されるコマンドの一例＞
次に、上述したシンク機器２０及びソース機器１０からなる映像処理システムで使用されるコマンドについて、以下に詳しく説明する。

図９は、本発明の一実施形態に係るシンク機器からソース機器に供給される電源オフメッセージに対する処理計画を問い合わせるコマンドの一例を示す説明図である。

図９において、Header BlockのInitiatorには、シンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して仮に『Standbyメッセージ』を送信した場合に、ソース機器１０がどのような処理（ここでは電源管理）を行うかを問い合わせることをOperand[０]で示している。論理アドレス、Imitiator、 Destination、EOM、ACKの詳細については、ＨＤＭＩ Specificationを参照のこと（以下同じ）。

図１０は、本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『即時電源オフ』を意味するコマンドの一例を示す説明図である。

図１０において、Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して、仮に『Standbyメッセージ』を送信した場合に、ソース機器１０が「即時電源オフ」することをOperand[１]のコード(０x００)で示している。

図１１は、本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『録画終了後電源オフ』を意味するコマンドの一例を示す説明図である。

図１１において、Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して、仮に『Standbyメッセージ』を送信した場合に、ソース機器１０が「録画終了後電源オフ」することをOperand[１]のコード(０x０１)で示している。

図１２は、本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『電源オン継続』を意味するコマンドの一例を示す説明図である。

図１２において、Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して、仮に『Standbyメッセージ』を送信した場合に、ソース機器１０が「電源オン継続」することをOperand[１]のコード(０x０２)で示している。

図１３は、本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『メッセージ画像がある』旨を意味するコマンドの一例を示す説明図である。

図１３において、Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して、仮に『Standbyメッセージ』を送信した場合に、ソース機器１０が「メッセージ画像がある」ことをOperand[１]のコード(０x０３)で示している。

図１４は、本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対する『メッセージ画像がある』旨を意味するコマンドに対して、シンク機器からソース機器に供給される『メッセージ画像を送れ』を意味するコマンドの一例を示す説明図である。

図１４において、Header blockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して「メッセージ画像の送出要求」をOperand[０]のコード(０x０３)で示している。

図１５は、本発明の一実施形態に係るシンク機器からソース機器に供給される、任意のメッセージに対する処理計画の更新状況を問い合わせるコマンドの一例を示す説明図である。

図１５において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して「任意のメッセージに対する処理計画の更新状況の通知要求」をOperand[０]のコード(０x５５)で示している。Operand[１]は他のコマンド構造との整合性をとるため設けたReserve Dataである。

続く任意のメッセージにはＨＤＭＩ Specification で規定されたメッセージを使用することを想定している。Operand[２]に配置されたHeader BlockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスへ通知する任意のコマンドがOperand[３]以降に記述される。ここではユーザからの操作が、機器の電源オフ操作であることをOperand[３]のコード(０x４４)及び、Operand[４]のコード(０x６c)で示している。

図１６は、本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がないことを示すコマンドの一例を示す説明図である。

図１６において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して「処理計画の更新状況の通知」をOperand[０]のコード(０x５６)で示している。Operand[１]は処理計画の更新が無いことをOperand[１]のコード(０x００)で示している。

続く任意のメッセージについてはＨＤＭＩ Specification で規定されたメッセージを使用することを想定している。Operand[２]に配置されたHeader BlockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスへ通知する任意のコマンドがOperand[３]以降に記述される。ここではユーザからの操作が、機器の電源オフ操作であることをOperand[３]のコード(０x４４)及び、Operand[４]のコード(０x６c)で示している。

図１７は、本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がｈｔｍｌ形式で存在することを示すコマンドの一例を示す説明図である。

図１７において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して「処理計画の更新状況の通知」をOperand[０]のコード(０x５６)で示している。Operand[１]は処理計画の更新がｈｔｍｌ形式で存在することをOperand[１]のコード(０x０１)で示している。

図１８は、本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がＸＭＬ形式で存在することを示すコマンドの一例を示す説明図である。

図１８において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して「処理計画の更新状況の通知」をOperand[０]のコード(０x５６)で示している。Operand[１]は処理計画の更新がＸＭＬ形式で存在することをOperand[１]のコード(０x０３)で示している。

図１９は、本発明の一実施形態に係るシンク機器からソース機器に供給される、ｈｔｍｌ形式の処理計画の送出を要求するコマンドの一例を示す説明図である。

図１９において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して「処理計画の送出要求」をOperand[０]のコード(０x５７)で示している。Operand[１]は更新された処理計画をｈｔｍｌ形式でＣＥＣ制御線を使って送出要求することをOperand[１]のコード(０x０１)で示している。

図２０は、本発明の一実施形態に係るシンク機器からソース機器に供給される、ＸＭＬ形式の処理計画の送出を要求するコマンドの一例を示す説明図である。

図２０において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される以降の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して「処理計画の送出要求」をOperand[０]のコード(０x５７)で示している。Operand[１]は更新された処理計画をＸＭＬ形式でアドレス／データ送受信線を使って送出要求することをOperand[１]のコード(０x０３)で示している。

図２１は、本発明の一実施形態に係るソース機器からシンク機器に供給される、応答メッセージ及び操作メッセージを示すコマンドの一例を示す説明図である。

図２１において、ここではＣＥＣ制御線でメッセージを送出することを想定している。メッセージ全体のサイズが不定なので複数のメッセージに分割して番号を付けて送出する。ここでは１つのメッセージサイズを２５６byteに制限している。Header blockのInitiatorにはソース機器１０の論理アドレスが入り、Destinationが示す論理アドレスのシンク機器２０に対して「ｈｔｍｌメッセージ」であることをOperand[０]のコード(０ｘＣＡ)で示している。Operand[１]には全てのｈｔｍｌメッセージが[Total]で示される数に分割されて送出されることを示している。Operand[２]は、当該メッセージが分割されたメッセージの[Count]番目であることを示している。Operand[３]は当該メッセージ中のペイロード数を[Message Length]で示している。Operand[４..n+３]はASCIIコードで示されるPayload（ｈｔｍｌメッセージデータ）である。Operand[n+４]は、当該メッセージ全体のチェックサムを示している。

図２２は、本発明の一実施形態に係るソース機器からシンク機器に供給される、応答メッセージ及び操作メッセージを示すコマンドの他の一例を示す説明図である。

図２２において、アドレス／データ送受信線を使ってメッセージを伝送することを想定している。メッセージ全体のサイズが不定なので複数のメッセージに分割して番号を付けて送出する。ここでは１つのメッセージサイズのPayloadを２５６byteに制限している。

S は伝送の開始を示すStart Conditionである。P は伝送の終了を示すStop Conditionである。Slave Address は７bitでデータのアドレスを指定する。W は１bitでデータの送出方向がソース機器１０からシンク機器２０であることを示す。Code[０]とCode[１] は各８bitで任意のメッセージコマンドを示す。Modeは応答メッセージの種類を示す。[total]は全ての応答メッセージが分割される数を示す。[count]は分割されたメッセージの何番目かを示す。[Length]はPayloadの数を示す。Payloadは応答データであり、１メッセージにつき最大２５６byteである。ＣＲＣは送出されたデータの正当性を検証するためのコードである。

最後に、図２３は、本発明の一実施形態に係るシンク機器からソース機器に供給される、処理計画の受信完了を通知するコマンドの一例を示す説明図である。

図２３において、コマンドは、Header BlockとOpecodeとOperand[０]及びOperand[１]で構成される要求コマンド部と、Operand[２]、Operand[３]及びOperand[４]で構成される実行予定の任意のメッセージを示すコマンド部から構成されている。Header blockのInitiatorにはシンク機器２０の論理アドレスが入り、Destinationが示す論理アドレスのソース機器１０に対して「処理計画情報の受信状況」をOperand[０]のコード(０x５８)で示している。Operand[１]は、処理計画の全てを受信完了したことを通知するコマンドである。

以上、コマンドの例を上げたが、本発明の実施形態はこれらのコマンドに限定されるものではなく、映像処理装置の間で通信され実行されるコマンドであれば、同様に使用が可能であり、本発明の実施形態に含まれるものである。

以上記載した様々な実施形態により、当業者は本発明を実現することができるが、更にこれらの実施形態の様々な他の実施形態を思いつくことが当業者によって容易であり、発明的な能力をもたなくとも様々な実施形態へと適用することが可能である。従って、本発明は、開示された原理と新規な特徴に矛盾しない広範な範囲に及ぶものであり、上述した実施形態に限定されるものではない。

本発明の一実施形態に係るシンク機器の映像処理装置とこれに接続されるソース機器の映像処理装置をもつ映像処理システムの一例を示すブロック図。本発明の一実施形態に係るソース機器である映像処理装置の構成の一例を示すブロック図。本発明の一実施形態に係るシンク機器である映像処理装置の構成の一例を示すブロック図。本発明の一実施形態に係る映像処理装置が有しているＨＤＭＩ端子の信号名を示す説明図。本発明が実施されない場合のシステム電源オフの際の機器制御動作の一例を示すフローチャート。本発明の第１の実施形態であるシンク機器及びソース機器の処理予測方法の一例を示すフローチャート。本発明の第２の実施形態であるシンク機器及びソース機器の処理予測方法の一例を示すフローチャート。本発明の第３の実施形態であるシンク機器及びソース機器のｈｄｍｌメッセージを用いた処理予測方法の一例を示すフローチャート。本発明の一実施形態に係るシンク機器からソース機器に供給される電源オフメッセージに対する処理計画を問い合わせるコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『即時電源オフ』を意味するコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『録画終了後電源オフ』を意味するコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『電源得オン継続』を意味するコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対して『映像メッセージがある』旨を意味するコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、問合せコマンドに対する『映像メッセージがある』旨を意味するコマンドに対して、シンク機器からソース機器に供給される『映像メッセージを送れ』を意味するコマンドの一例を示す説明図。本発明の一実施形態に係るシンク機器からソース機器に供給される、任意のメッセージに対する処理計画の更新状況を問い合わせるコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がないことを示すコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がｈｔｍｌ形式で存在することを示すコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、任意のメッセージに対する処理計画の更新処理がＸＭＬ形式で存在することを示すコマンドの一例を示す説明図。本発明の一実施形態に係るシンク機器からソース機器に供給される、ｈｔｍｌ形式の処理計画の送出を要求するコマンドの一例を示す説明図。本発明の一実施形態に係るシンク機器からソース機器に供給される、ＸＭＬ形式の処理計画の送出を要求するコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、応答メッセージ及び操作メッセージを示すコマンドの一例を示す説明図。本発明の一実施形態に係るソース機器からシンク機器に供給される、応答メッセージ及び操作メッセージを示すコマンドの他の一例を示す説明図。本発明の一実施形態に係るシンク機器からソース機器に供給される、処理計画の受信完了を通知するコマンドの一例を示す説明図。

符号の説明

１０…ソース機器、２０…シンク機器、１１…映像送信部、１２…コマンド送受信部、１４…制御部、１４−１…処理予測部、１３…映像生成部、２１…映像受信部、２２…コマンド送受信部。

Claims

他の映像処理装置から通信路を介して第１速度で映像音声信号を受信し、前記他の映像処理装置と前記通信路を介して前記第１速度より低速な第２速度で制御信号の通信を行う通信部と、
前記通信部の行なう前記制御信号の通信処理であって、所定コマンドに対する処理計画の送信を要求する要求信号を前記他の映像処理装置に送信し、同じく前記通信部の行なう前記制御信号の通信処理であって、前記他の映像処理装置から前記所定コマンドに対する処理計画を示すメッセージ信号を受信し、これにより、前記所定コマンドの実行を要求された際に、前記メッセージ信号が示す所定コマンドに対する処理計画を表示する画像を生成する処理予測部と、
前記通信部を介して受信した前記映像音声信号に応じた画像を表示すると共に、前記処理予測部が生成した前記所定コマンドに対する処理計画を表示する画像を画面上に表示する表示部と、を具備することを特徴とする映像処理装置。
前記処理予測部が扱う所定コマンドは、前記他の映像処理装置の電源をオフにする制御信号であることを特徴とする請求項１記載の映像処理装置。
前記処理予測部が生成した処理計画を表示する画像は、前記他の映像処理装置の処理計画と共に、可能な操作の選択肢を同時に表示することを特徴とする請求項１の記載の映像処理装置。
前記表示部は、前記他の映像処理装置からのメッセージ画面の存在を制御信号として受けると、このメッセージ画面を、可能な操作の選択肢を同時に表示することを特徴とする請求項１の記載の映像処理装置。
前記処理予測部は、予め前記他の映像処理装置からメッセージ画像を制御信号として取得しておき、その後、このメッセージ画像が更新されていれば、更新されたメッセージ画像を更に取得して表示することを特徴とする請求項１の記載の映像処理装置。
前記処理予測部は、前記他の映像処理装置から、前記所定コマンドに対する処理計画を示すメッセージ信号をｈｔｍｌ形式で受信することを特徴とする請求項１記載の映像処理装置。
前記処理予測部は、前記他の映像処理装置から、前記所定コマンドに対する処理計画を示すメッセージ信号をＸＭＬ形式で受信することを特徴とする請求項１記載の映像処理装置。
前記処理予測部は、前記通信部のＨＤＭＩ規格のＣＥＣ信号線を介して、前記所定コマンドに対する処理計画を示すメッセージ信号を受信することを特徴とする請求項１記載の映像処理装置。
前記処理予測部は、前記通信部のＨＤＭＩ規格のＤＤＣ信号線を介して、前記所定コマンドに対する処理計画を示すメッセージ信号を受信することを特徴とする請求項１記載の映像処理装置。
前記処理予測部は、前記他の映像処理装置から、前記所定コマンドに対する処理計画を示すメッセージ信号を受けて、ブラウザ機能を用いて、前記メッセージ信号が示す所定コマンドに対する処理計画を表示する画像信号を生成して出力することを特徴とする請求項１記載の映像処理装置。
前記処理予測部が生成した前記メッセージ信号が示す所定コマンドに対する処理計画を表示する画像信号の出力に対して操作信号を受信したら、この操作信号に応じて前記所定コマンドを実行する制御部を更に有することを特徴とする請求項１記載の映像処理装置。
映像音声信号を通信路を介して受信し再生する第１の映像処理装置と、前記第１の映像処理装置と前記通信路を介して接続されており、前記映像音声信号を前記通信路を介して前記第１の映像処理装置に供給する第２の映像処理装置をもつ映像処理システムであって、
前記第１の映像処理装置は、
前記第２の映像処理装置から前記通信路を介して第１速度で映像音声信号を受信し、前記第２の映像処理装置と前記通信路を介して前記第１速度より低速な第２速度で制御信号の通信を行う第１通信部と、
前記第１通信部の行なう前記制御信号の通信処理であって、所定コマンドに対する処理計画の送信を要求する要求信号を前記第２の映像処理装置に送信し、前記第２の映像処理装置から前記所定コマンドに対する処理計画を示すメッセージ信号を受信し、前記所定コマンドの実行を要求された際に、前記メッセージ信号が示す所定コマンドに対する処理計画を表示する画像を生成する第１処理予測部と、
前記通信部を介して受信した前記映像音声信号に応じた画像を表示すると共に、前記処理予測部が生成した前記所定コマンドに対する処理計画を表示する画像を画面上に表示する表示部を有しており、
前記第２の映像処理装置は、
前記映像音声信号を生成する生成部と、
前記生成部からの前記映像音声信号を前記通信路を介して前記第１の映像処理装置へ前記第１速度で供給すると共に、前記第１の映像処理装置と前記通信路を介して前記第２速度で制御信号の通信を行う第２通信部と、
前記第２通信部の行なう前記制御信号の通信処理であって、前記所定コマンドに対する処理計画の送信を要求する要求信号を前記第１の映像処理装置から受信し、前記第１の映像処理装置へ前記所定コマンドに対する処理計画を示すメッセージ信号を送信する第２処理予測部を有していることを特徴とする映像処理システム。