(57)【要約】【課題】ＭＰＥＧ−４等の動画で提供される情報を、より多くの視聴者に情報を効果的に早く伝達することができる画像処理装置及びその方法、並びにコンピュータプログラム及びコンピュータ可読記憶媒体を提供することを目的とする。【解決手段】動画コンテンツ入力部１で動画データを入力し、制御情報入力部６で出力先が理解できるようなデータ形式を設定し、シーン更新検出部４で動画データのシーン更新を検出し、シーン・データ作成部５で検出されたシーンのシーン・データを、前記データ形式で作成する。【選択図】　　　　図１
2004128872.tif 000002
【特許請求の範囲】
【請求項１】
動画データを入力する動画データ入力手段と、
出力先の機器が理解できるようなデータ形式を設定するデータ形式設定手段と、
前記動画データのシーン更新を検出するシーン更新検出手段と、
前記シーン更新検出手段によって検出されたシーンのシーン・データを、前記データ形式で作成するシーン・データ作成手段とを有することを特徴とする画像処理装置。
【請求項２】
前記出力先の機器は、外部装置であることを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記外部装置との間のデータ伝送を制御する通信制御手段と、
前記通信制御手段から入力された受信データを解析する受信データ解析手段と、
前記通信制御手段に適合する送信形式にデータを整形する送信データ整形手段を有し、
前記受信データ解析手段は、前記通信制御手段によって前記外部装置から受信した受信データからデータ形式を抽出して、前記データ形式を前記データ形式設定手段に与えることを特徴とする請求項２に記載の画像処理装置。
【請求項４】
前記シーン・データ作成手段によって作成されるシーン・データの位置と出現順序を示すインデックス・データを、前記データ形式で作成するインデックス・データ作成手段を有することを特徴とする請求項２又は請求項３に記載の画像処理装置。
【請求項５】
前記通信制御手段は、前記インデックス・データ作成手段で作成されたインデックス・データを前記外部装置に送信することを特徴とする請求項４に記載の画像処理装置。
【請求項６】
前記シーン・データ作成手段で作成されたシーン・データと前記インデックス・データ作成手段で作成されたインデックス・データを結合して出力するデータ結合出力手段を有することを特徴とする請求項４又は請求項５に記載の画像処理装置。
【請求項７】
前記動画データ入力手段によって入力される動画データにはシーンを記述するシーン記述データを含み、前記シーン更新検出手段は、前記シーン記述データに基づいてシーンの更新を判定することを特徴とする請求項１〜６の何れか１項に記載の画像処理装置。
【請求項８】
前記動画データ入力手段によって入力される動画データは、前記シーン・データ作成手段で作成されるデータ形式とは異なるデータ形式のデータであることを特徴とする請求項１〜７の何れか１項に記載の画像処理装置。
【請求項９】
動画データを入力する動画データ入力工程と、
出力先の機器が理解できるようなデータ形式を設定するデータ形式設定工程と、
前記動画データ入力工程で入力された動画データのシーン更新を検出するシーン更新検出工程と、
前記シーン更新検出工程で検出されたシーンのシーン・データを、前記データ形式設定工程で設定されたデータ形式で作成するシーン・データ作成工程とを有することを特徴とする画像処理方法。
【請求項１０】
前記出力先の機器は、外部装置であることを特徴とする請求項９に記載の画像処理方法。
【請求項１１】
前記シーン・データ作成工程で作成されたシーン・データの位置と出現順序を示すインデックス・データを、前記データ形式で作成するインデックス・データ作成工程を有することを特徴とする請求項９又は請求項１０に記載の画像処理方法。
【請求項１２】
前記動画データ入力工程で入力される動画データにはシーンを記述するシーン記述データを含み、前記シーン更新検出工程は、前記シーン記述データに基づいてシーンの更新を判定することを特徴とする請求項９〜１１の何れか１項に記載の画像処理方法。
【請求項１３】
前記動画データ入力工程で入力される動画データは、前記シーン・データ作成工程で作成されるデータ形式とは異なるデータ形式のデータであることを特徴とする請求項９〜１２の何れか１項に記載の画像処理装置。
【請求項１４】
請求項９〜１３の何れか１項に記載の画像処理方法を実行するコンピュータプログラム。
【請求項１５】
請求項１４に記載のプログラムを格納し、コンピュータが読み取り可能なコンピュータ可読記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、画像処理装置及びその方法、並びにコンピュータプログラム及びコンピュータ可読記憶媒体に関し、特にマルチメディア符号化形式の動画データから他形式の静止画データ生成に関する。
【０００２】
【従来の技術】
近年、デジタル・ビデオ・カメラが広く普及してきている。その形態もノートパソコンや携帯端末等のネットワーク通信機能を有する機器に接続できるようになっていたり、あるいは携帯電話と一体化していたりと様々な形態をとるようになってきている。こういった形態が採用される背景には、ビデオ・カメラで撮影した動画データを電子メールで送付したり、ネットワーク上で送信したりして、離れた場所からでも動画を見られるようにしたいと望んでいる消費者が存在することを示すものであると言えるだろう。
【０００３】
こういった背景を踏まえて、動画データの符号化圧縮技術も、ネットワーク通信技術と連携して用いられることを想定してこれまでに様々な改善、拡張がなされてきた。ＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｏｒｇａｎｉｚａｔｉｏｎ　ｆｏｒ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）によって標準化されているマルチメディア符号化形式であるＭＰＥＧ−４は、その代表とも言えるものである。ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）−４は、ネットワーク環境で利用されることを前提に、それまでの動画符号化形式であるＭＰＥＧ−１、ＭＰＥＧ−２の圧縮方法を大幅に改善し、高い圧縮効率が実現されている。
【０００４】
このＭＰＥＧ−４の実現によって、かつては広いデータ伝送帯域幅が要求されるため、ＤＶＤなどの蓄積媒体や放送などの領域でしか用いられなかったＭＰＥＧの動画符号化技術が、インターネット環境のような比較的限られた帯域幅の環境においても利用出来るようになってきた。
【０００５】
実際に、最近になってＭＰＥＧ−４や、米国Ｍｉｃｒｏｓｏｆｔ社によって定義されているＡＳＦ（Ａｄｖａｎｃｅｄ　Ｓｔｒｅａｍｉｎｇ　Ｆｏｒｍａｔ）形式のようなＭＰＥＧ−４を基盤とする動画符号化形式を扱うことの出来るデジタル・ビデオ・カメラやネットワーク・ビデオ・プレーヤーなど、多種の製品が市場に投入されてきている。特に、本明細書の記述時点（平成１４年７月）では、ＮＴＴドコモ社による第三世代移動体通信サービスであるＦＯＭＡ（登録商標）において、ＭＰＥＧ−４を用いたデジタル動画像通信サービスが「ｉモーション（登録商標）」という名称ですでに開始されていることもあり、動画通信を行うことの出来る製品は今後さらに増えるであろうし、コンテンツ提供者もこれまでの静止画、テキストデータに加えて、より訴求力の高い情報を提供できる動画によるコンテンツを流通させる機会が増えるだろうと予想される。
【０００６】
しかし、一般的には動画データを再生できるのは、再生対象の動画データの符号化形式を正しく解析する仕組みを備えている再生装置に限られる。そのため、動画符号化データの解析手段を持たない装置では動画の再生が出来ないという問題点がある。
【０００７】
この問題は、パーソナル・コンピュータ等の装置上で動作するＷＷＷブラウザで動画データを再生する場合であれば、大きな問題になる可能性は少ない。米国Ｎｅｔｓｃａｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社のＮｅｔｓｃａｐｅ　Ｎａｖｉｇａｔｏｒ（登録商標）、もしくは米国Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ　Ｅｘｐｌｏｒｅｒ（登録商標）といった代表的なＷＷＷブラウザには、未知のデータ形式の検出時に、その形式を解析する手段を備えた「プラグイン」あるいは「ＡｃｔｉｖｅＸコントロール」として知られるプログラム・モジュールをネットワーク経由で取得し、ＷＷＷブラウザの拡張機能としてインストールする機能がサポートされているため、再生する動画データ形式に対応したモジュールを取得することで再生は可能になるからである。
【０００８】
しかし、携帯電話のような端末機器は諸々の制約から機能が限定されていることが多いため、通常はこういった機能はサポートされておらず、あらかじめ機器に組み込まれた形式のデータ以外は表示することが出来ない。そればかりか、現状では動画はおろか静止画データ形式しか表示できない機器も依然として多いため、そのような機種の利用者は、動画コンテンツを視聴する事が出来なくなってしまう。
【０００９】
加えて、このようなソフトウェア的な制約でなく、物理的な制約によって動画データを視聴できないような機器も存在しうる。例えば、プリンタやＦＡＸのように、データを紙に印刷することによって出力する機器のような場合は、もはやデータを動画として視聴することは不可能である。
【００１０】
また、端末機器が仮にＭＰＥＧ−４形式のデータを解析できたとしても、ＭＰＥＧ−４の種類によっては、端末機器で視聴できない可能性が生じる場合がある。ＩＳＯでは、ＭＰＥＧ−４標準の一部として、ビデオやオーディオ、その他テキストや図形などのデータを「オブジェクト」として扱い、このオブジェクト群を表示画面上に空間的、時間的に配置した「シーン」を記述するためのＢＩＦＳ（Ｂｉｎａｒｙ　Ｆｏｒｍａｔ　ｆｏｒ　Ｓｃｅｎｅｓ）と呼ばれるデータ符号化形式を規定している。このＢＩＦＳ情報が加わることによって、普通の動画よりもさらに表現力の高いコンテンツが提供できるようになっている。しかしながら、このようにＭＰＥＧ−４には複数のレベルが存在していることによって、たとえＭＰＥＧ−４形式をサポートする再生機器であったとしても、ＭＰＥＧ−４動画符号化データは解析可能だがＢＩＦＳの処理機能はサポートしていない機器の場合は、このコンテンツは全く視聴不可能となってしまう。
【００１１】
以上に述べられるように、現状では、動画コンテンツを作成してネットワーク上に流通させても、必ずしも視聴者の機器で動画が再生できるとは限らないため、コンテンツ作成者が意図する情報を相手の視聴者に伝達できなかったり、あるいは限られた視聴者にしか伝達することが出来ないといった問題がある。
【００１２】
上記の問題に加えて、動画データとして情報を伝達する場合には、「内容を把握しづらく、所望する情報にたどり着くまでに時間がかかる」という、よく知られている動画特有の問題もついて回る。
【００１３】
動画情報は、静止画情報やテキスト情報と異なり、時間軸を持つという特徴的な性質を持っている。その性質ゆえに、動画情報の内容を把握するためには動画を先頭から末尾まで再生してみなければならないため、視聴者に内容を伝達するために必要な時間は、静止画やテキスト等の情報と比較してどうしても長くなってしまう。
【００１４】
また、動画情報が視聴者にとって有用なものであるか、また、有用な部分が動画中のどの位置に存在するかは、視聴してみなければ知ることは出来ない。そのため、視聴者にとって無用の情報であったとしても、結局、動画を先頭から再生し、内容を確認しながら視聴してみなければならず、視聴者は所望の情報に至るまで、ずっと不要な情報の視聴を強いられることになる。そのため、視聴者が動画コンテンツを視聴し、そこから必要な情報を取得することは、多大な時間とストレスを要する非効率的なものになりかねない。
【００１５】
さらに、動画情報をネットワーク経由で取得する場合は再生時間に加えてデータ取得のための通信時間が必要となるため、視聴者に強いられる時間とストレスはさらに増大する。しかも、ネットワークが公衆網の場合にはデータ通信に伴う回線使用料金の負担も強いられるという問題もある。圧縮されているとはいえ、動画データのデータ・サイズは非常に大きなものであるので、ネットワーク経由でデータを取得する時間や費用は決して無視できるものではない。
【００１６】
従来、動画からシーン静止画を抽出する技術、およびインデックスを出力する技術として、ビデオ・データ中のフレームを表す静止画と、その画像に付随する音声説明や字幕をテキスト化したデータを配置したインデックス・データを提供する方法がある（例えば、非特許文献１参照。）。また、この方法をふまえて、インターネット／ワールド・ワイド・ウェブ等の通信ネットワーク上のビデオ・ブラウジングをサポートする方法もある（例えば、特許文献１参照）。
【００１７】
【特許公報１】
特開平９−２４４８４９号公報
【非特許公報１】
Ａｍｙ　Ｔ．Ｉｎｃｒｅｍｏｎａ著、「Ａｕｔｏｍａｔｉｃａｌｌｙ　ｔｒａｎｓｃｒｉｂｉｎｇ　ａｎｄ　Ｃｏｎｄｅｎｓｉｎｇ　Ｖｉｄｅｏ：Ｎｅｗ　Ｔｅｃｈｎｏｌｏｇｙ　ｉｓ　Ｂｏｒｎ」、ＡＤＶＡＮＣＥＤ　ＩＭＡＧＩＮＧ、１９９５年８月
【００１８】
【発明が解決しようとする課題】
上記のように、動画コンテンツは多くの再生機器で正しく再生できない可能性があり、また、コンテンツの内容を容易に把握できないため、コンテンツ作成者が伝達したい情報を、視聴者に対して確実かつわかりやすく提供することが困難であるという問題があった。
【００１９】
本発明は、上記の課題を解決するためになされたものであり、ＭＰＥＧ−４等の動画で提供される情報を、内容を容易に把握できるようなシーン静止画データとして、インターネット等のネットワークを介して広範な端末機器で視聴できるような形式で提供することで、より多くの視聴者に情報を効果的に早く伝達することができる画像処理装置及びその方法、並びにコンピュータプログラム及びコンピュータ可読記憶媒体を提供することを目的とする。
【００２０】
【課題を解決するための手段】
上記の目的を達成するため、本発明に係る画像処理装置は、動画データを入力する動画データ入力手段と、出力先の機器が理解できるようなデータ形式を設定するデータ形式設定手段と、前記動画データのシーン更新を検出するシーン更新検出手段と、前記シーン更新検出手段によって検出されたシーンのシーン・データを、前記データ形式で作成するシーン・データ作成手段とを有することを特徴とする。
【００２１】
上記の目的を達成するため、本発明に係る画像処理方法は、動画データを入力する動画データ入力工程と、出力先の機器が理解できるようなデータ形式を設定するデータ形式設定工程と、前記動画データ入力工程で入力された動画データのシーン更新を検出するシーン更新検出工程と、前記シーン更新検出工程で検出されたシーンのシーン・データを、前記データ形式設定工程で設定されたデータ形式で作成するシーン・データ作成工程とを有することを特徴とする。
【００２２】
【発明の実施の形態】
以下に、本発明の実施の形態を図面を参照しながら説明する。図１は、本発明の全体構成を示す図であり、本発明を実現する装置を構成する機能ブロックを示したものである。
【００２３】
動画コンテンツ入力部１は、ＭＰＥＧ−４のようなマルチメディア符号化形式のデジタル・データとして記録されている動画コンテンツ・データを取り込むためのものである。入力される動画コンテンツは、コンピュータ上のディスク装置やＣＤなどの記録媒体、あるいはネットワークを介した遠隔地の装置といった場所に保管されるが、これらの場所からコンテンツ・データを取得して、後続の処理を実行出来るよう内部記憶へ展開する処理が行われる。
【００２４】
コンテンツ非多重化部２は、動画コンテンツ入力部１から送られる動画コンテンツ・データが多重化された複数のデータ列から構成されている場合に、非多重化処理を行うためのものである。ＭＰＥＧ−４の場合は、動画データと一緒に、音声データやその他の種類のデータを単一のデータ列に多重化するＦｌｅｘＭｕｘと呼ばれる多重化方法がＩＳＯによって規格化されているが、コンテンツ非多重化部２は、例えばこのＦｌｅｘＭｕｘ形式で多重化されたデータ列から動画データを分離するといった処理が行われる。なお、このような多重化処理は、全てのデータに対して必ずしも行われていなくても良いため、入力されたコンテンツが多重化されていない場合は、多重化処理はスキップされる。ここで分離されたデータ列は、符号化データ解析部３に渡される。
【００２５】
符号化データ解析部３は、コンテンツ非多重化部２から送られるデータ・ブロックの符号化データを解析し、デコード等のデータ処理を行うためのものである。マルチメディア・データは一般的にデータ量を縮小するための圧縮符号化がなされているが、その場合はここで圧縮データの展開処理が行われる。また、ＩＳＯで規定されているコンテンツ保護標準であるＩＰＭＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ　Ｐｒｏｐｅｒｔｙ　Ｍａｎａｇｅｍｅｎｔ　ａｎｄ　Ｐｒｏｔｅｃｔｉｏｎ）等の仕組みを用いてデータの暗号化がなされている場合は、ここで復号処理が行われる。なお、マルチメディア・コンテンツは、ビデオやオーディオ、静止画像や、それらの相互関連やレイアウト情報を記述するためのデータ等、複数のタイプのデータから構成される場合があるが、符号化データ解析部３は入力されるデータ・タイプに応じた適切な解析処理を行う手段を有するものとする。
【００２６】
シーン更新検出部４は、符号化データ解析部３で処理されたデータ・ブロックを受け取り、そのデータ・ブロックに対応する動画像中のシーンが変更されたかどうかを判断し、更新の検出を行うためのものである。例えばＭＰＥＧ−４の場合、前述のＢＩＦＳを用いることによって、コンテンツ中のシーンが切り替わることをその更新時刻とともに明示的に示すことが出来る。ＢＩＦＳを用いたシーン更新については追って説明するが、シーン更新検出部４ではＢＩＦＳで示されたシーン更新データのような、何らかのシーンの変化を示す信号を検出する処理が行われる。更新が検出されたら、更新時刻をデータ作成制御部８に受け渡す。
【００２７】
シーン・データ作成部５は、先行する機能ブロックから渡されたシーンを表現するデータを、視聴者が静止画像として視聴することが可能なデータ形式にして出力するためのものである。ここでは、例えばＭＰＥＧ−４形式で符号化された動画データ中の所定の時刻のシーンを、ＪＰＥＧ（Ｊｏｉｎｔ　Ｐｈｏｔｏｇｒａｐｈｉｃ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）、ＧＩＦ（Ｇｒａｐｈｉｃｓ　Ｉｎｔｅｒｃｈａｎｇｅ　Ｆｏｒｍａｔ）等の静止画像符号化形式のデータに変換して、画像ファイルやメモリー・ブロックに出力する処理が行われる。対象となるシーンの時刻は、シーン更新検出部４によって取得されたシーン更新時刻を、データ作成制御部８から取得する。ここで出力された画像データの位置は、後述のデータ作成制御部８に受け渡される。
【００２８】
制御情報入力部６は、本発明の画像処理装置に対して、どのような処理を行い、どのような形式のデータを生成するかを指示する制御情報を取り込むためのものである。インデックス・データを作成するための制御情報として入力されるデータには、最終的に出力されるデータの符号化形式や、生成するデータの精度などを指定する。例えば、視聴者の端末でＪＰＥＧ、ＨＴＭＬを処理することが出来、表示可能な最大サイズが１７６×１４４ピクセルであるような場合は、”ＪＰＥＧ，　ＨＴＭＬ”、”１７６×１４４”といったデータが制御データとして用いられることになる。制御データは、画像処理装置内にあらかじめ記録されているか、装置の操作者によって入力されるか、あるいはネットワークを介して端末機器から送付される等の手段で入力される。
【００２９】
制御情報解析部７は、制御情報入力部６によって取得された制御データを解析し、後続のデータ作成制御部９が制御に用いることが出来る形式に変換するためのものである。制御データは、操作者から入力されたりネットワークを介して送られる場合、一般的には文字列形式のデータとして入力されるが、制御情報解析部７はこのデータを画像処理装置が処理しやすい任意の形式に変換する処理を行う。ここで変換されるデータは装置内部でしか使用されないため、内部的に処理しやすい形式であればどのような形式であっても良い。
【００３０】
データ作成制御部８は、制御情報解析部７から渡された制御データに基づいて、シーン・データ作成部５、インデックス・データ作成部９、データ結合部１０で行われるデータ生成処理の挙動を制御するためのものである。また、シーン更新検出部４で検知されたシーンの更新、および、例えばシーン更新の発生した時刻やシーン静止画ファイルの位置などといったシーン更新に付随する情報を受け取り、制御情報として内部的に保持する。
【００３１】
インデックス・データ作成部９は、シーン更新検出部４で検出されたシーン更新情報に基づき、更新されたシーンを表す静止画像データの位置、およびその出現順序を記述するインデックス・データを作成するためのものである。インデックス・データは、シーン画像ファイルのＵＲＬ文字列など、シーン・データの位置を特定するためのデータ・ポインター値や、あるいはシーン画像データそのものが記録され、シーン・データを参照あるいは包含することが可能な形式で作成されるものとする。このインデックス・データは、視聴者の端末で処理可能なデータ形式になっていても良い。例えば、視聴者の端末がＪＰＥＧ、ＨＴＭＬが処理可能な場合は、インデックス・データ作成部９は静止画データが時系列に並べられたＨＴＭＬデータをインデックス・データとして生成するようにしても良い。なお、この制御に必要な処理可能データ形式、シーン更新発生時刻、シーン静止画の位置といった制御情報は、データ作成制御部８から取得することが出来る。
【００３２】
データ結合部１０は、インデックス・データ作成部９で生成されたインデックス・データと、シーン・データ作成部５で生成されたシーン・データとを結合するためのものである。ここでは、例えばインデックス・データがＨＴＭＬの場合は、参照される静止画が正しく参照できるようなＵＲＬを再設定するといったように、両者の関連情報に矛盾がないか等のチェック処理を行う。また、端末で処理可能なデータ形式によっては、インデックス・データとシーン・データとが統合された単一のデータ形式として出力するといった処理も行われる場合もある。統合化されたデータ形式の例としては、ＨＴＭＬデータにＵＲＬで外部参照されるＪＰＥＧファイルのバイナリ・データを埋め込み、単一のアーカイブＨＴＭＬファイルや、シーン画像が出現順にレイアウトされたＪＰＥＧデータのような単一の画像データ、または時間的にレイアウトされたＭｏｔｉｏｎ　ＪＰＥＧのようなデータといったものがありえる。データ結合部１０の処理結果は、視聴者が視聴することが可能な符号化形式で、最終的なコンテンツ・データとして出力される。
【００３３】
受信データ解析部１１は、制御情報入力部６に渡される制御情報がネットワーク経由で送付される場合に、ネットワークから受信されたデータを解析し、制御情報を抽出するためのものである。
【００３４】
送信データ整形部１２は、データ結合部１０で生成された最終的なコンテンツ・データを外部の装置や媒体に何らかの伝送手段を介して送出する場合に、送信形態に応じてデータを適切な形に整形するためのものである。
【００３５】
通信制御部１３は、外部の装置および媒体からデータを送受信するためのものである。外部とのデータ伝送のための制御手段を有し、受信データ解析部１２あるいは送信データ整形部１２からデータの取得および送出を行うために利用される。
【００３６】
一般的に、データをネットワーク上で送受信する場合は、通信プロトコルに応じた通信制御情報がデータに付加されたり、通信を効率的に行えるようにデータを最適化したりする処理が行われる。そのため、受信データ解析部１１、送信データ整形部１２、通信制御部１３で扱われるデータは、必ずしもコンテンツ・データの本来のデータ内容とは一致していないことがある。そのため、これらの機能ブロックでは、通信処理に関連する部分のデータに対する解釈や整形処理が行われるが、コンテンツ・データ自体に対するデータ処理が行われるのではないことに注意されたい。ゆえに、本発明の画像処理装置がネットワーク経由でのデータ送受信を必要としない場合には、受信データ解析部１１、送信データ整形部１２、通信制御部１３は必要ではない。
【００３７】
続いて、本発明の画像処理装置の基本原理について、図面を参照しながら以下に説明する。
【００３８】
まず、本発明では、前記従来技術の項で述べた「動画データとして伝達される情報は、内容を把握しづらく、所望する情報にたどり着くまでに時間がかかる」という問題に対して、動画データ中のある時間的なポイントにおける一場面を示す「シーン」を走査して、シーンの切り替えが行われたこと示す信号を検出し、切り替えが発生した時点のシーンのイメージを静止画像データとして出力したシーン・データと、シーン・データの位置とシーンの前後関係がわかるように出現順を記述したインデックス・データを生成し、これらを視聴者が閲覧することが可能な符号化データ形式で提示する。視聴者はこの出力によって動画のシーン構成を知ることが出来るため、おおよその内容を把握することが出来る。
【００３９】
図３は、シーン・データ、およびインデックス・データの一例をし、ＭＰＥＧ−４形式で記録された元の動画コンテンツ・ファイルｍｏｖｉｅ．ｍｐ４から、シーン切り替えが発生した時点のシーン・データとインデックス・データを抽出して、シーン・データをｍｏｖｉｅ−０００１．ｊｐｇ〜ｍｏｖｉｅ−０００５．ｊｐｇといったＪＰＥＧファイル、インデックス・データをｍｏｖｉｅ．ｈｔｍｌといったＨＴＭＬファイルとして出力されることを示している。ｍｏｖｉｅ．ｈｔｍｌにはシーン・データを示すＪＰＥＧファイルのＵＲＬが記述されていることによって、ｍｏｖｉｅ．ｈｔｍｌを表示装置で表示させると、図中に示されるようなシーン静止画が時系列で配置されたイメージの出力結果が得られる。
【００４０】
そして、本発明では、このようなデータとして出力される動画コンテンツの概要情報を、視聴者が利用する端末機器が適切に扱うことが可能なデータ形式に変換して提供するようにしている。このことによって、端末機器の表示性能の違いを吸収し、動画の内容をより多くの視聴者へ情報を伝達することを可能にしている。
【００４１】
したがって、本発明で生成されるデータ形式は、必ずしも図３で説明したように、静止画像データの形式としてＪＰＥＧ、インデックス・データの形式としてＨＴＭＬのみが用いられる訳ではない。視聴者が利用する端末機器によっては、静止画像データはＧＩＦ、ＰＮＧ（Ｐｏｒｔａｂｌｅ　Ｎｅｔｗｏｒｋ　Ｇｒａｐｈｉｃｓ）等の形式で出力されなければならない場合もある。インデックス・データも、表示能力に劣る端末機器向けの形式としてインターネット標準規格化団体であるＷ３Ｃ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ　Ｃｏｎｓｏｒｔｉｕｍ）によって提案されているＣｏｍｐａｃｔ　ＨＴＭＬや、同様にＷＡＰ　Ｆｏｒｕｍによって提案されているＷＭＬ（Ｗｉｒｅｌｅｓｓ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）等、端末機器に適する形式の構造化言語で出力される場合もある。さらに、シーン静止画を空間的のみならず時間的に配置するため、前記Ｗ３Ｃによって標準化が行われているＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｇｒａｔｅｄ　Ｌａｎｇｕａｇｅ）のように、時間的表現が可能なプレゼンテーション用の構造化言語で記述される場合もある。
【００４２】
また、シーン・データとインデックス・データは、図１のデータ結合部１０によって単一の出力データに統合される場合もある。例えば、前記したように外部参照されるシーン静止画ファイルのデータをＨＴＭＬに埋め込んだアーカイブＨＴＭＬとして出力する以外にも、Ａｎｉｍａｔｉｏｎ　ＧＩＦやＭｏｔｉｏｎ　ＪＰＥＧ形式ファイルのように、シーン静止画が出現順に並べられた単一の連続静止画ファイルのような形式で出力する場合もある。
【００４３】
もちろん、端末機器でサポートされていれば、米国Ａｐｐｌｅ　Ｃｏｍｐｕｔｅｒ社で定義されているマルチメディア・データ形式であるＱｕｉｃｋＴｉｍｅ（登録商標）のように、複数の静止画ファイルを単一のファイルに包含させることが出来るような形式で提示されても良い。
【００４４】
また、端末機器でＭＰＥＧ−４のような動画データ形式の再生をサポートしている場合であっても、従来の技術の項で述べたようにＭＰＥＧ−４でも様々なレベルの規格が存在するため、端末機器で再生可能なレベルのＭＰＥＧ−４データ形式に再変換して提示してもよい。
【００４５】
その他、上記のデータ形式以外であっても、端末機器で出力可能な形式であれば、どのようなデータ形式で提示されてもよい。例えば、端末機器がプリンタ等の場合は、上記のようなラスター形式のデータではなく、ＰｏｓｔＳｃｒｉｐｔ、ＰＤＦ（Ｐｏｒｔａｂｌｅ　Ｄｏｃｕｍｅｎｔ　Ｆｏｒｍａｔ）のような形式で提示されても良い。
【００４６】
動画コンテンツの概要情報が端末機器にどのようなデータ形式で出力されるかの具体例を、図４に示す。図４は、動画インデックス・データが提示される端末機器および各端末に提示される際のデータ形式の例を示す図であり、端末機器として（１）携帯情報端末機、（２）携帯電話機、（３）パーソナル・コンピュータ、（４）ゲーム機、（５）プリンタがある場合に、本発明の画像処理装置によって生成されたデータを、（１）にはＨＴＭＬとＪＰＥＧ、（２）にはＣｏｍｐａｃｔ　ＨＴＭＬとＧＩＦ、（３）にはＳＭＩＬ　（Ｓｙｎｃｈｒｏｎｉｚｅｄ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｇｒａｔｉｏｎ　Ｌａｎｇｕａｇｅ）とＪＰＥＧ、（４）にはＡｎｉｍａｔｉｏｎ　ＧＩＦ、（５）にはＰｏｓｔＳｃｒｉｐｔとして提供していることを示している。
【００４７】
なお、本発明では、動画データのシーン変更を検出するための手段として、動画コンテンツ・データの符号化形式として前記ＢＩＦＳデータを含むＭＰＥＧ−４形式で記録されている場合は、ＢＩＦＳの仕様の一部である「ＢＩＦＳ　Ｃｏｍｍａｎｄ」と呼ばれる機能を利用する。
【００４８】
説明の際の予備知識として、ＭＰＥＧ−４の「ＢＩＦＳ　Ｃｏｍｍａｎｄ」の概要について、以下にごく簡単に説明しておく。
【００４９】
図２は、複数のオブジェクト・データからシーンを合成する概念を示す図であす。ＭＰＥＧ−４では、図２で示されるように、複数のオブジェクトによって動画中のシーンを構成することが出来る。このオブジェクト・データは、それぞれが固有のデータ・ストリームを持ち、さらに、オブジェクトが空間的、時間的にどのように配置されるかを示すためにＢＩＦＳ形式で記述されるシーン記述情報、およびオブジェクトのデータ・ストリームとシーン記述情報とを関連付けるためのオブジェクト・ディスクリプタ情報を持つ。これらの情報は、図５で示されるようにシーン合成手段に入力され、最終的なシーンとして合成される。図５は、ＭＰＥＧ−４のシーンが、シーン記述（ＢＩＦＳ）、オブジェクト・ディスクリプタ、オブジェクト・データによって合成されることを表現する図である。
【００５０】
ＭＰＥＧ−４では、上記ＢＩＦＳデータの一部として、シーンを構成するオブジェクトを挿入、削除、置換したり、あるいはシーン自体を置換したりするための操作を表すコマンド・データの記述方式を規定している。このコマンド・データが「ＢＩＦＳＣｏｍｍａｎｄ」であり、ＢＩＦＳ　Ｃｏｍｍａｎｄデータをコンテンツ中に含めることによって、シーンの更新を制御することが可能になっている。なお、前記ＩＳＯより発行されるＩＳＯ／ＩＥＣ　１４９９６−１標準文書にＢＩＦＳ　Ｃｏｍｍａｎｄを含むＢＩＦＳの完全な仕様が記述されているので、詳細についてはそちらを参照されたい。
【００５１】
本発明では、入力されるコンテンツ・データに含まれるＢＩＦＳ　Ｃｏｍｍａｎｄデータ、あるいはそれに類する何らかのコマンド・データによってシーンに何らかの変更が加えられたことが示されたポイントを、シーン更新が発生したポイントとして扱うことによって、シーン更新の検出手段とする。
【００５２】
次に、本発明の基本原理の実施の形態について、以下に例を挙げて説明する。
【００５３】
＜実施の形態１＞
実施の形態１として、本発明の画像処理装置が、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）を使用できるインターネット・サーバー機上で動作するソフトウェア・プログラムとして動作する場合の形態について説明する。この形態の典型例は、通信制御部１３や受信データ解析部１２などはＡｐａｃｈｅなどのＨＴＴＰサーバー・プログラムで、その他の機能ブロックはＣＧＩ（Ｃｏｍｍｏｎ　Ｇａｔｅｗａｙ　Ｉｎｔｅｒｆａｃｅ）プログラムなどとして実現されると思われる。また、視聴者の利用する端末機器は、図４（１）の携帯情報端末機器を想定する。
【００５４】
実施の形態１では、画像処理装置に対してデータの生成方法を指示するためのデータ作成制御データは、図６のように端末機器からＨＴＴＰで伝送される。図６は、動画インデックス・データ生成装置に対して、制御データをＨＴＴＰで伝送する際のデータ形式を示す図である。端末機器からは、図中で示されるように、処理対象の動画コンテンツ・データの位置を示すＵＲＬ（／ｃｇｉ／ｂｉｎ／ｍｖｉｎｄｅｘ．ｅｘｅ？ｍｏｖｉｅ．ｍｐ４　）、端末機器で処理可能なデータ形式（Ａｃｃｅｐｔ：　ｔｅｘｔ／ｐｌａｉｎ，　ｔｅｘｔ／ｈｔｍｌ，　ｉｍａｇｅ／ｊｐｅｇ）、端末機器あるいは表示のためのプログラムの種類を識別する名称（ＭｏｖｉｅＰｌａｙｅｒ／１．０）などがデータ作成制御データとして、ＨＴＴＰで送信されるデータのヘッダー部に記述されて送信されるものとする。無論、データ作成制御データはＨＴＴＰのヘッダー部ではなく、データ本体として送信されても良いことは言うまでもない。
【００５５】
送信されたデータ作成制御データは、通信制御部１３から受信データ解析部１１を経て動画コンテンツ・データのＵＲＬ（／ｃｇｉ／ｂｉｎ／ｍｖｉｎｄｅｘ．ｅｘｅ？ｍｏｖｉｅ．ｍｐ４）が取り出され、画像処理装置を実行するＣＧＩプログラムに渡される。この処理は、本形態では、ＨＴＴＰによるリクエストからヘッダー部分を抽出し、ＣＧＩプログラムに受け渡すといった、ＨＴＴＰサーバー・プログラムが通常備えている機能を用いて実現される。なお、本形態では通信制御部とデータ処理部が分離しているため、ＵＲＬに処理対象の動画コンテンツ・データのファイル名（ｍｏｖｉｅ．ｍｐ４）とデータ処理部が実装されたＣＧＩプログラムのＵＲＬ（／ｃｇｉ／ｂｉｎ／ｍｖｉｎｄｅｘ．ｅｘｅ）が同時に指定されているが、通信制御部とデータ処理部が同一のプログラムとして動作する場合にはコンテンツ・データのファイル名のみを指定出来る。
【００５６】
コンテンツ・データを指定するための方法として、ファイル名以外にも、コンテンツに関連付けられた任意形式の識別子などを使用しても良い。ただし、使用されるデータは、何らかの方法で処理対象のコンテンツ・データを特定することが出来るものでなければならない。
【００５７】
受信されたデータ作成制御データは、制御情報入力部６を介して、制御情報解析部７に渡される。制御情報解析部７では、入力された制御情報を解析し、内部記憶に取り込む処理が行われる。以下、制御情報解析部７で行われる解析処理を、図７のフローチャートを用いて順を追って説明する。
【００５８】
図７は、制御情報解析部８において実行される処理を示すフローチャートである。
【００５９】
（ステップＳ７１）制御情報入力部６から渡されたデータ作成制御データを取得する。
【００６０】
本形態の例では、図６で示されるようにＨＴＴＰのヘッダー部分に記述されたデータ作成制御データは、ＨＴＴＰサーバー・プログラムによって環境変数の形でＣＧＩプログラムに渡される。図６の例で言えば、”Ｕｓｅｒ−Ａｇｅｎｔ”など、”：”より左の部分に示される項目に対応して定義された環境変数に、”ＭｏｖｉｅＰｌａｙｅｒ／１．０”などの”：”より右の部分のデータが代入される。また、１行目のＵＲＬの”？”より右の部分は、”ＱＵＥＲＹ＿ＳＴＲＩＮＧ”という環境変数に代入される。その結果、ＣＧＩプログラムとして実装される制御情報解析部７には、
”ＨＴＴＰ＿ＡＣＣＥＰＴ＝ｔｅｘｔ／ｐｌａｉｎ，　ｔｅｘｔ／ｈｔｍｌ，　ｉｍａｇｅ／ｊｐｅｇ”
”ＨＴＴＰ＿ＵＳＥＲ＿ＡＧＥＮＴ＝ＭｏｖｉｅＰｌａｙｅｒ／１．０”
”ＱＵＥＲＹ＿ＳＴＲＩＮＧ＝ｍｏｖｉｅ．ｍｐ４”
といった環境変数が利用可能となる。
【００６１】
（ステップＳ７２）制御項目およびその項目が示すデータを内部記憶に保存する。
【００６２】
ここで、本形態の例では、環境変数ＨＴＴＰ＿ＡＣＣＥＰＴ、ＨＴＴＰ＿ＵＳＥＲ＿ＡＧＥＮＴ、ＱＵＥＲＹ＿ＳＴＲＩＮＧが制御項目として用いられると仮定すると、これらの環境変数で示されるデータを、後続の処理で利用可能な形式で内部記憶に保存する。
【００６３】
本形態の例では、制御項目として利用可能な環境変数名とそのデータとを連想配列形式のデータ構造中にそれぞれ文字列形式で記憶すると仮定する。ただし、内部記憶に保存される時の形態は、それが後続の処理で利用可能である限りはどのようなものであっても良い。例えば、ＨＴＴＰ＿ＡＣＣＥＰＴのデータ部は、処理可能なデータ形式をコンマで繋げて列記した単一の文字列データとして記述されているが、保存する際には文字列データ中に列記された個々のデータ形式を抽出してリスト形式で保存するといったように、任意の形式変換等の処理を行っても良い。
【００６４】
（ステップＳ７３）入力されたすべてのデータ作成制御データに対して解析処理が行われたら、コンテンツ・データの位置情報を動画コンテンツ入力部１に通知する。
【００６５】
本形態の例では、環境変数ＱＵＥＲＹ＿ＳＴＲＩＮＧの値”ｍｏｖｉｅ．ｍｐ４”がコンテンツ・データの位置情報に相当するため、この”ｍｏｖｉｅ．ｍｐ４”が動画コンテンツ入力部１に渡される。なお、場合によっては、コンテンツ・データの位置情報が絶対パスの形式で渡されることが望ましいことがありえるが、その場合は位置情報を上記のような相対ＵＲＬ形式から絶対パス形式に変換する処理も動画コンテンツ入力部１に受け渡す前に行われると仮定する。
【００６６】
ただし、本形態のように、位置情報が環境変数として展開され、動画コンテンツ入力部１からでも参照することが可能になっている場合は、この処理は必ずしも行われなくても良い。
【００６７】
（ステップＳ７４）上記ステップＳ７１の処理によって内部記憶に保持された制御情報を、データ作成制御部８に受け渡す。渡された制御情報は、そのままデータ作成制御部８によって管理される。
【００６８】
本形態では、ステップＳ７１で述べたようなデータ構造のポインタが渡されるものと仮定する。
【００６９】
以上の手順によって、データ作成制御データが解析され、コンテンツ・データの位置情報が動画コンテンツ入力部１に渡される。
【００７０】
一方、動画コンテンツ・データは、制御情報解析部７から受け渡された位置を元に動画コンテンツ入力部１によって取得され、コンテンツ非多重化部２による非多重化処理、符号化データ解析部３による符号化データの解析処理を経た後、シーン更新検出部４に渡される。シーン更新検出部４では、入力された符号化データ中からシーンの変更を示す情報を捜し、ここで変更が検出されたシーンが、後続の処理で静止画を抽出する対象として取り扱われる。以下、シーン更新検出部４で行われる検出処理を、図８のフローチャートを用いて順を追って説明する。なお、シーン更新検出部４で処理されるデータは、すでにコンテンツ非多重化部２によって動画、静止画、シーン記述などのそれぞれのデータ形式毎に分離されたデータ列として渡されているものとする。また、分離されたデータ列には、ＭＰＥＧ−４の規格において定義されるＤＴＳ（Ｄｅｃｏｄｉｎｇ　Ｔｉｍｅ　Ｓｔａｍｐ）、ＣＴＳ（Ｃｏｍｐｏｓｉｔｉｏｎ　Ｔｉｍｅ　Ｓｔａｍｐ）といった、データ列に含まれる所定のブロックがいつ処理されるべきであるかを示す時刻情報が埋め込まれているものとする。
【００７１】
図８は、シーン更新検出部４において実行される処理を示すフローチャートである。
【００７２】
（ステップＳ８１）まず、入力された符号化データの種類を確認する。
【００７３】
本形態では、入力された符号化データの種類は、前述のオブジェクト・ディスクリプタ情報によって判定する。オブジェクト・ディスクリプタ情報には、コンテンツ中に含まれるオブジェクトの内容が記述されたデータ・ストリーム（Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ）の構成情報や符号化形式の種類などが記述されている。例えば、オブジェクト・ディスクリプタの一種であるＩｎｉｔｉａｌ　Ｏｂｊｅｃｔ　Ｄｅｓｃｒｉｐｔｏｒには、コンテンツに含まれるＥｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍの特性情報を記述するＥＳ＿Ｄｅｓｃｒｉｐｔｏｒ、符号化形式の特性情報を記述するＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒといった情報がまとめて記述されている。ＩＳＯの定義では、符号化データの種類は、上記のＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒの項目ｓｔｒｅａｍＴｙｐｅによって指定されるようになっており、この値によって識別可能となっている。符号化データ解析部３では、符号化データをあらかじめ解析し、シーン更新検出部の各処理で利用可能な形態にしておく必要がある。本形態では符号化データ解析部３で符号化データの種類等を含むオブジェクト・ディスクリプタ情報やストリームデータ自身の解析処理が行われるものとする。
【００７４】
なお、オブジェクト・ディスクリプタ情報をはじめとするＭＰＥＧ−４による符号化については、ＩＳＯ／ＩＥＣ　１４４９６−１の規格文書に完全な定義が記載されているため、本明細書では詳細にわたる説明は省略する。
【００７５】
（ステップＳ８２）入力された符号化データの種類が、ＢＩＦＳを示すものであるかチェックする。ＢＩＦＳの場合はステップＳ８３の処理を実行し、さもなければステップＳ８５の処理までスキップする。
【００７６】
本形態の場合は、符号化データの種類は上記ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒの項目ｓｔｒｅａｍＴｙｐｅで指定され、ＢＩＦＳの場合はｓｔｒｅａｍＴｙｐｅの値が０ｘ０３となっている。したがって、ここではｓｔｒｅａｍＴｙｐｅ＝０ｘ０３であるかどうかをチェックする。
【００７７】
（ステップＳ８３）入力されたＢＩＦＳデータが、ＢＩＦＳ　Ｃｏｍｍａｎｄであるかチェックする。ＢＩＦＳ　Ｃｏｍｍａｎｄの場合はステップＳ８４の処理を実行し、さもなければステップＳ８５の処理までスキップする。
【００７８】
本形態の場合は、ＢＩＦＳ　Ｃｏｍｍａｎｄを検出することによってシーンに何らかの変更が発生したことを判断しているため、ＢＩＦＳデータ中にＢＩＦＳ　Ｃｏｍｍａｎｄが含まれているかをチェックする必要がある。ＢＩＦＳ　Ｃｏｍｍａｎｄは、通常、Ｃｏｎｄｉｏｎａｌと呼ばれる種類のオブジェクトの属性データとして記述されるため、ここではＢＩＦＳデータ中にＣｏｎｄｉｔｉｏｎａｌオブジェクト、およびその属性として記述されたＢＩＦＳ　Ｃｏｍｍａｎｄデータが含まれるかどうかをチェックする。
【００７９】
（ステップＳ８４）シーンの更新が検出されたら、更新の内容と更新が発生する時刻とをデータ作成制御部８に受け渡すことによって、シーンの更新を通知する。データ作成制御部８は、これらのシーン更新情報を内部記憶に保持し、後続のデータ生成処理の制御に用いられるよう管理しておく。
【００８０】
本形態の場合は、更新の内容は、コマンドの種類（追加／削除／置換／シーン置換）を示すＢＩＦＳ　Ｃｏｍｍａｎｄの属性ｃｏｄｅの値によって判断することが可能である。ｃｏｄｅには、０（オブジェクトの挿入）、１（オブジェクトの削除）、２（オブジェクトの置換）、３（シーンの置換）の４種類の値が定義されている。また、更新が発生する時刻は、ＢＩＦＳ　Ｃｏｍｍａｎｄに対して割り当てられているＣＴＳ（Ｃｏｍｐｏｓｉｔｉｏｎ　Ｔｉｍｅ　Ｓｔａｍｐ）が用いられる。したがって、ここではＢＩＦＳ　Ｃｏｍｍａｎｄのｃｏｄｅ値、およびＣＴＳの値を取得し、それぞれを更新内容、更新発生時刻としてデータ作成制御部８に渡している。
【００８１】
（ステップＳ８５）入力されたデータがすべて処理されたかどうかチェックする。未処理の入力データが残っている場合は、残りのデータに対してステップＳ８１〜ステップＳ８４の処理を行う。
【００８２】
以上の手順によって、シーン更新検出部４に入力された符号化データからシーンの変更を示す情報が検出される。
【００８３】
シーン・データ作成部５では、図９で示される手順で、シーン更新検出部４から渡されたシーン情報を元に、可視形式の画像フォーマットで記録されたシーン静止画データの作成処理を行う。以下、図９のフローチャートを用いてシーン・データ作成部５の処理を順を追って説明する。
【００８４】
図９は、シーン・データ作成部５において実行される処理を示すフローチャートである。
【００８５】
（ステップＳ９１）データ作成制御部８から、入力されたシーンの更新時刻に対応するタイムスタンプを取得する。
【００８６】
（ステップＳ９２）データ作成制御部８から、視聴者が利用する端末機器で処理可能なデータ形式の情報を取得する。
【００８７】
その際、作成される静止画データの形式は視聴者の端末機器で表示できる形式で出力される必要があるため、まず、データ作成制御部８に対して、端末機器で受け付けられるデータ形式を問い合わせる。本形態の例では、処理可能なデータ形式は図７の説明で示されるように、”ＨＴＴＰ＿ＡＣＣＥＰＴ＝ｔｅｘｔ／ｐｌａｉｎ，　ｔｅｘｔ／ｈｔｍｌ，　ｉｍａｇｅ／ｊｐｅｇ”という環境変数として取得されたのちデータ作成制御部８に渡され、管理されている。したがって、ＨＴＴＰ＿ＡＣＣＥＰＴに対応するデータはデータ作成制御部８から取得可能である。
【００８８】
（ステップＳ９３）入力されたシーン情報を、ステップＳ９２で取得された処理可能なデータ形式の静止画フォーマットで符号化し、シーンの静止画データを作成する。
【００８９】
本形態では、ステップＳ９４で取得されるデータ中には、ＨＴＴＰ＿ＡＣＣＥＰＴの”ｉｍａｇｅ／ｊｐｅｇ”として、ＪＰＥＧ形式の静止画データを受け付けることが出来ることを示すデータが含まれているため、ここではＪＰＥＧ形式の符号化処理を実行し、シーン静止画をＪＰＥＧ形式のファイルとして出力するようにする。もちろん、このデータが”ｉｍａｇｅ／ｇｉｆ”となっている場合はＧＩＦ形式で出力する等の動的な制御が必要であることは言うまでもない。
【００９０】
なお、ここで出力される画像ファイルは、図３で示されるように、”ｍｏｖｉｅ−０００１．ｊｐｇ”〜”ｍｏｖｉｅ−０００５．ｊｐｇ”というファイル名で作成されるものとする。
【００９１】
ただし、図５で示されるように、シーンが複数のオブジェクトによって構成されている場合は、静止画データを作成する前に、シーンを構成するオブジェクトの表示位置や、その他表示属性を示すデータを抽出し、その情報に基づいて仮想空間上にオブジェクトを配置してから、その配置イメージを静止画データとして出力しなければならない。
【００９２】
なお、この合成処理はＭＰＥＧ−４で複数のオブジェクトを取り扱う場合には必須の処理であるが、本発明の目的とは直接関係しないので、合成処理の実施方法に関する詳しい説明は省略する。
【００９３】
（ステップＳ９４）ステップＳ９３で出力された静止画データの位置を、シーン更新が発生した時刻と関連付けてデータ作成制御部８に通知する。ここで生成される静止画データは、静止画データ・ファイルに出力されても良いし、メモリー・ブロックに出力されても良い。したがって、データ作成制御部８に通知されるデータの位置は、静止画データ・ファイルの場合はファイル・パス、メモリー・ブロックの場合はアドレス値などが用いられることになる。本形態で示される例では、出力形態はＪＰＥＧ形式等の静止画像ファイルとし、データ作成制御部８には静止画データ・ファイル名が通知されるものとする。
【００９４】
データ作成制御部８は、シーン・データ作成部５から受け渡された静止画データの位置を、同じく受け渡されたタイムスタンプ関連付けて保持する。さらに、データ作成制御部８は受け取った静止画データの位置をインデックス・データ作成部９に渡して、後述されるインデックス・データの作成処理の実行を指示する。
【００９５】
上記ステップＳ９１〜ステップＳ９４までの一連の流れが処理されたら、動画コンテンツ入力部１に入力される次の入力データに対して、図８〜図９で示される処理を繰り返し行っていく。
【００９６】
以上の手順によって、シーン更新検出部４から渡されたシーン情報から、可視形式の画像フォーマットで記録されたシーン静止画データが作成される。ここまでの処理によって生成されたシーン静止画データは、最終的にインデックス・データ作成部９によって生成されるインデックス・データから参照される。以下、インデックス・データ作成部９で行われる処理を、図１０を用いて順を追って説明する。
【００９７】
図１０は、インデックス・データ作成部において実行される処理を示すフローチャートである。
【００９８】
（ステップＳ１０１）データ作成制御部８から静止画データの位置を受け取る。
【００９９】
（ステップＳ１０２）端末機器で処理可能なデータ形式をデータ作成制御部９に問い合わせ、取得する。
【０１００】
本形態では、図７の説明で示されるように、処理可能なデータ形式は”ＨＴＴＰ＿ＡＣＣＥＰＴ＝ｔｅｘｔ／ｐｌａｉｎ，　ｔｅｘｔ／ｈｔｍｌ，　ｉｍａｇｅ／ｊｐｅｇ”という環境変数として取得されたのちデータ作成制御部８に渡され、管理されている。したがって、ここではこのＨＴＴＰ＿ＡＣＣＥＰＴに対応するデータをデータ作成制御部８から取得する。
（ステップＳ１０３）静止画データの位置を、ステップＳ１０１で取得された形式を元に、適切な形式のインデックス・データに記録し、出力する。
【０１０１】
本形態の場合、ステップＳ１０２で取得されるデータ中には、”ｔｅｘｔ／ｈｔｍｌ”として、ＨＴＭＬ形式のデータを受け付けられることを示すデータが含まれているので、インデックス・データ作成部９はインデックス・データを図３に示される”ｍｏｖｉｅ．ｈｔｍｌ”という名称のＨＴＭＬ形式のファイルとして出力するようにしている。また、本形態では、静止画データの位置としてファイル名が用いられているため、インデックス・データには参照される静止画のファイル名が指定されたＩＭＧタグのデータが出力されるものとする。
【０１０２】
なお、ここで作成されるインデックス・データは、必ずしも視聴者の端末機器で再生可能なデータ形式で作成されていなくてもよい。この例では、端末機器はＨＴＭＬを処理することが出来るためインデックス・データをＨＴＭＬ形式で出力しているが、例えばＪＰＥＧ形式しか処理することが出来ない端末機器の場合には、ＨＴＭＬ形式のインデックス・データは処理できない。
【０１０３】
このような場合、インデックス・データには静止画の順序や配置情報などを記録した任意形式のデータとして作成し、後続のデータ結合部１０でインデックス・データの情報とシーン静止画データを結合し、端末機器で処理可能な形式で出力するようにしなければならない。すなわち、ここで挙げられたＪＰＥＧ形式しか処理できない機器に対しては、データ結合部１０では複数のシーン静止画がレイアウトされた一枚のＪＰＥＧ画像を生成するといった処理が必要となるだろう。
【０１０４】
このようなケースでは、インデックス・データ作成部９は任意の形式でインデックス・データを生成しても良い。
【０１０５】
（ステップＳ１０４）ステップＳ１０３で出力されたインデックス・データの位置をデータ作成制御部８に通知する。
【０１０６】
本形態の場合は、ステップＳ１０３で出力されたインデックス・データのファイル名”ｍｏｖｉｅ．ｈｔｍｌ”がデータ作成制御部８に渡される。
【０１０７】
なお、インデックス・データ作成部９では、静止画データの位置が通知された時点でインデックス・データを内部記憶上に作成しておき、すべてのシーンの処理が完了した時点で最終的なインデックス・データ形式に変換、出力する処理を行うようにしても良い。したがって、データ作成制御部８に通知されるインデックス・データの位置は、本形態の場合はＨＴＭＬファイル・パスであるが、内部記憶のアドレス値などを用いても良い。
【０１０８】
以上図７〜図１０の処理によって、動画コンテンツに含まれるシーンへのインデックス・データが作成される。
【０１０９】
すべてのシーンに対して、図７〜図１０の処理が完了したら、データ作成制御部９はデータ結合部１０を呼び出し、これまでに登録されたインデックス・データの位置および静止画データの位置を渡す。本形態では、データ結合部１０では、出力されたＨＴＭＬファイルに記述されたＪＰＥＧファイルへの参照が正しいか、あるいは、ＵＲＬがローカル環境で使用されるファイル・パスなどで記述されている場合に、正しく参照できるＵＲＬに変換する処理などが行われる。
【０１１０】
さらに、端末機器に対してインデックス・データとシーン・データがパッケージされた単一のデータとして提示される必要がある場合は、ここでデータの結合処理を行う。
【０１１１】
例えば、図１０のフローチャートの説明中に挙げられたような、ＪＰＥＧ形式しか処理できない機器や、あるいは図４のゲーム機（４）、プリンタ（５）のような機器に対しては、ここまでの処理で作成されたインデックス・データとシーン・データを統合して、端末機器で処理可能な形式で出力する。データの結合処理を行う際に、インデックス・データ、およびシーン・データを別の符号化形式に変換する必要がある場合は、データ結合部１０では必要な符号化形式変換や再符号化処理を行わなければならない。
【０１１２】
データ結合部１０で処理されたデータは、最終的に、送信データ整形部１２でＨＴＴＰのレスポンス・データとして整形され、通信制御部１３を介して視聴者の端末機器に送信される。
【０１１３】
このような手段によって生成された動画インデックス・データは、視聴者の利用する端末機器がサポートする形式で生成されることが保証されるため、視聴者は確実に動画情報の内容を知ることが可能になる。
【０１１４】
本実施例では、シーン・データと共にインデックス・データを生成したが、シーン・データのみを生成し、生成されたシーン・データを次々と端末装置に転送し、表示するものでも構わない。シーン・データのみを生成する場合は、すべてのシーン・データを生成する前に、生成されたシーン・データを見ることができ、視聴者に内容をより早く伝達することができる。また、シーン・データとインデックス・データを生成する場合は、視聴者がすべてのシーン・データを一度に見ることができ、例えば端末機器がプリンタ等である場合に適している。
【０１１５】
また、本実施例では、シーン更新検出に、シーン操作のためのコマンド・データ（ＢＩＦＳコマンド）を用いたので、容易にシーン更新検出が可能である。
【０１１６】
また、本実施例では、インデックス・データとシーン・データを結合し、ひとまとめにすることで、ネットワークを通じた送受信の手間が軽減し、また、データの管理も容易になる。
【０１１７】
＜その他の実施形態＞
また、上記実施形態では、ネットワークを構成するハードウェア等が含まれるものの、各処理部は実際はソフトウェアで実現できるものである。即ち、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または、記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（または、ＣＰＵやＭＰＵ）が、記憶媒体に格納されたプログラムコードを読み出し、実行することによっても達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が、上述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体が本発明を構成することになる。
【０１１８】
また、コンピュータが読み出したプログラムコードを実行することにより、上述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）等が、実際の処理の一部または全部を行い、その処理によって、上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１１９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が、実際の処理の一部または全部を行い、その処理によって、上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１２０】
また、上記実施形態では、データ作成制御情報を入力して、データ形式を設定しているが、いくつかのデータ形式から選択して行ってもよいのは言うまでもない。
【０１２１】
【発明の効果】
以上説明したように、本発明によれば、ＭＰＥＧ−４等の動画コンテンツで提供される情報に対し、内容を容易に把握できるようなシーン静止画データを、インターネット等のネットワークを介して広範な端末機器で視聴できるような形式で提供することが可能となり、その結果、より多くの視聴者に情報を効果的に早く伝達することが可能となる。
【図面の簡単な説明】
【図１】本発明の全体構成を示す図である。
【図２】複数のオブジェクト・データからシーンを合成する概念を示す図である。
【図３】シーン・データ、インデックス・データの例を示す図である。
【図４】動画インデックス・データが提示される端末機器および各端末に提示される際のデータ形式の例を示す図である。
【図５】ＭＰＥＧ−４のシーンが、シーン記述（ＢＩＦＳ）、オブジェクト・ディスクリプタ、オブジェクト・データによって合成されることを表現する図である。
【図６】画像処理装置に対して、制御データをＨＴＴＰで伝送する際のデータ形式を示す図である。
【図７】制御情報解析部７において実行される処理を示すフローチャートである。
【図８】シーン更新検出部４において実行される処理を示すフローチャートである。
【図９】シーン・データ作成部５において実行される処理を示すフローチャートである。
【図１０】インデックス・データ作成部９において実行される処理を示すフローチャートである。
【図１】
2004128872.tif 000003
【図２】
2004128872.tif 000004
【図３】
2004128872.tif 000005
【図４】
2004128872.tif 000006
【図５】
2004128872.tif 000007
【図６】
2004128872.tif 000008
【図７】
2004128872.tif 000009
【図８】
2004128872.tif 000010
【図９】
2004128872.tif 000011
【図１０】
2004128872.tif 000012