(57)【特許請求の範囲】
【請求項１】
記録媒体に記録された映像音声ストリームのアクセス単位の再生時刻情報、位置情報およびサイズを含む第１のアドレスマップを管理するアドレス管理手段と、
前記映像音声ストリームの通常再生および早送り再生を含む再生条件に基づいて、それぞれの再生単位を決定する再生位置管理手段と、
前記第１のアドレスマップに記録されたアクセス単位の再生時刻情報、位置情報およびサイズを元に前記再生位置管理手段において決定された前記再生単位に対応した再生時刻情報、位置情報およびサイズを含む第２のアドレスマップを生成する第２のアドレスマップ生成手段と、
前記第２のアドレスマップに基づいて前記再生単位を前記記録媒体から読出すストリーム制御手段と、
前記ストリーム制御手段によって前記記録媒体から読み出された前記再生単位を復号するデコード制御手段と
を備えたことを特徴とする映像音声再生装置。
【請求項２】
記録媒体に記録された映像音声ストリームのアクセス単位の再生時刻情報、位置情報およびサイズを含む第１のアドレスマップを管理するアドレス管理手段と、
前記映像音声ストリームの早送り再生を含む再生条件に基づいて、再生単位を決定する再生位置管理手段と、
前記第１のアドレスマップに記録されたアクセス単位の再生時刻情報、位置情報およびサイズを元に前記再生位置管理手段において決定された前記再生単位に対応した再生時刻情報、位置情報およびサイズを含む第２のアドレスマップを生成する第２のアドレスマップ生成手段と、
前記第２のアドレスマップに基づいて前記再生単位を前記記録媒体から読出すストリーム制御手段と、
前記ストリーム制御手段によって前記記録媒体から読み出された前記再生単位を復号するデコード制御手段とを備え、
前記再生条件が早送り再生の場合には、前記第２のアドレスマップ生成手段は、前記ストリーム制御手段が前記第２のアドレスマップに基づいて指定された前記再生単位に対応するストリームの読出し処理の完了前または完了時に、次の再生単位に対応する第２のアドレスマップを生成することを特徴とする映像音声再生装置。
【請求項３】
再生条件が早送り再生の場合には、第２のアドレスマップ生成手段は、ストリーム制御手段が前記第２のアドレスマップに基づいて指定された前記再生単位に対応するストリームの読出し処理の完了前または完了時に、次の再生単位に対応する第２のアドレスマップを生成することを特徴とする請求項１記載の映像音声再生装置。
【請求項４】
再生位置管理手段は、再生条件が早送り再生の場合、キーフレームを再生単位として決定することを特徴とする請求項１乃至請求項３のいずれか一項に記載の映像音声再生装置。
【請求項５】
再生位置管理手段は、再生条件が早送り再生の場合、キーフレームを含む複数のフレームを再生単位として決定することを特徴とする請求項１乃至請求項３のいずれか一項に記載の映像音声再生装置。
【請求項６】
記録媒体に記録された映像音声ストリームのアクセス単位の再生時刻情報、位置情報およびサイズを含む第１のアドレスマップを管理するアドレス管理ステップと、
前記映像音声ストリームの通常再生および早送り再生を含む再生条件に基づいて再生単位を決定する再生位置管理ステップと、
前記第１のアドレスマップに記録されたアクセス単位の再生時刻情報、位置情報およびサイズを元に前記再生位置管理ステップにおいて決定された前記再生単位に対応した再生時刻情報、位置情報およびサイズを含む第２のアドレスマップを生成する第２のアドレスマップ生成ステップと、
前記第２のアドレスマップに基づいて前記再生単位を前記記録媒体から読出すストリーム制御ステップと、
前記ストリーム制御ステップにおいて前記記録媒体から読み出された前記再生単位を復号するデコード制御ステップとを備えたことを特徴とする映像音声再生方法。
【請求項７】
記録媒体に記録された映像音声ストリームのアクセス単位の再生時刻情報、位置情報およびサイズを含む第１のアドレスマップを管理するアドレス管理ステップと、
前記映像音声ストリームの早送り再生を含む再生条件に基づいて再生単位を決定する再生位置管理ステップと、
前記第１のアドレスマップに記録されたアクセス単位の再生時刻情報、位置情報およびサイズを元に前記再生位置管理ステップにおいて決定された前記再生単位に対応した再生時刻情報、位置情報およびサイズを含む第２のアドレスマップを生成する第２のアドレスマップ生成ステップと、
前記第２のアドレスマップに基づいて前記再生単位を前記記録媒体から読出すストリーム制御ステップと、
前記ストリーム制御ステップにおいて前記記録媒体から読み出された前記再生単位を復号するデコード制御ステップとを備え、
前記再生条件が早送り再生の場合には、前記第２のアドレスマップ生成ステップは、前記ストリーム制御ステップが前記第２のアドレスマップに基づいて指定された前記再生単位に対応するストリームの読出し処理の完了前または完了時に、次の再生単位に対応する第２のアドレスマップを生成するステップである
ことを特徴とする映像音声再生方法。
【請求項８】
再生条件が早送り再生の場合には、前記第２のアドレスマップ生成ステップは、前記ストリーム制御ステップが前記第２のアドレスマップに基づいて指定された前記再生単位に対応するストリームの読出し処理の完了前または完了時に、次の再生単位に対応する第２のアドレスマップを生成するステップであることを特徴とする請求項６記載の映像音声再生方法。
【請求項９】
再生位置管理ステップは、再生条件が早送り再生の場合、キーフレームを再生単位として決定することを特徴とする請求項６乃至請求項８のいずれか一項に記載の映像音声再生方法。
【請求項１０】
再生位置管理ステップは、再生条件が早送り再生の場合、キーフレームを含む複数のフレームを再生単位として決定することを特徴とする請求項６乃至請求項８のいずれか一項に記載の映像音声再生方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記録媒体から映像音声情報を読出して再生する場合において、通常の再生に対して速度および再生方向の少なくとも一方を変更した、例えば早送り、早巻戻しなどの特殊再生を実現するためのストリームの処理方法および処理装置に関するものである。
【背景技術】
【０００２】
デジタル映像および音声データが記録さている記録媒体にはＭＰＥＧ(Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ)方式で符号化およびデータ圧縮が行なわれた映像および音声データのストリームが記録されている。この記録媒体に記録されている映像情報データを再生するシステムにおいては、ＭＰＥＧ方式で記録されている映像および音声データを復号化およびデータ伸張してデジタル映像および音声データを再生している。
【０００３】
しかしながら、ＭＰＥＧを構成するＩ、Ｐ、Ｂの各ピクチャの符号化長さは可変長であり、さらには、映像の複雑度や動きによって符号量が上下する可変ビットレートを採用しているために、再生するストリームに対して、指定したい時間に対応する先頭からのオフセットデータ量（オフセットアドレス）が特定できなかった。また、指定した位置から再生を行う場合、先頭のピクチャから乱れなく再生を開始するためには、先頭のピクチャが、自らのピクチャ内のデータから復元可能なＩピクチャを特定する必要があった。そこで、記録時にＩピクチャのデータ位置（アドレス情報）および時間情報に対応させたインデックスファイルを生成し、再生時にインデックスファイルに記録されたＩピクチャのアドレス情報と時間情報とを元にして、再生する位置を特定する技術があった（例えば特許文献１参照）。
【０００４】
また、早送りなどの特殊再生用のピクチャのみを記録媒体から読み出して、復号化処理を行う場合に、Ｉピクチャのデータサイズが大きいために、秒あたりに必要なピクチャ数の読出しができない問題が生じていた。これに対して、再生処理開始前に記録媒体から任意のＩピクチャを読み出す時間を計算するために用いる各種値を取得し、Ｉピクチャのみを表示する特殊再生時に本測定値を用いながら実際に記録媒体から次に読み出すべきＩピクチャを選択することによって、スムーズな特殊再生を実現する方法があった（例えば特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−２２４５４３号公報（第５頁、第２図）
【特許文献２】特開２００９−２６０６６９号公報（段落００１０〜００１１、図８）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、各Ｉピクチャのアドレス情報と時間情報とが記載されたアドレスマップから、次に再生すべきストリームの位置であるアドレスを指定して再生する従来の方法では、早送り再生などで、連続的かつ高速にＩピクチャのインデックス情報を読み出しストリームを読み出す処理に送らなければならない場合に、Ｉピクチャの情報の伝達遅れが発生することによってＩピクチャの読出し処理が遅れ、結果として、早送り再生がスムーズに行われない場合があった。また、再生処理開始前に記録媒体から任意のＩピクチャを読み出す時間を計算するために用いる各種値を取得し、Ｉピクチャのみを表示する特殊再生時に本測定値を用いながら実際に記録媒体から次に読み出すべきＩピクチャを選択する従来の方法でも、連続的かつ高速にＩピクチャの読み出す時間に関する各種値をストリームを読み出す処理に送らなければならない場合に、Ｉピクチャの情報の伝達遅れが発生することによってＩピクチャの読出し処理が遅れ、結果として、早送り再生がスムーズに行われない場合があった。
【０００７】
この発明は、上記のような課題を解決するためになされたものであり、その目的は、記録媒体に記録された映像音声ストリームに対して、Ｉピクチャなどのキーフレームを使った早送りなど、通常再生よりも高速な再生を行う場合において、キーフレームの読み出しを途切れなく行い、スムーズな映像表示を行う映像音声再生装置および映像音声再生方法を提供することである。
【課題を解決するための手段】
【０００８】
この発明に係る映像音声再生装置においては、
記録媒体に記録された映像音声ストリームのアクセス単位の再生時刻情報、位置情報およびサイズを含む第１のアドレスマップを管理するアドレス管理手段と、
前記映像音声ストリームの通常再生および早送り再生を含む再生条件に基づいて、それぞれの再生単位を決定する再生位置管理手段と、
前記第１のアドレスマップに記録されたアクセス単位の再生時刻情報、位置情報およびサイズを元に前記再生位置管理手段において決定された前記再生単位に対応した再生時刻情報、位置情報およびサイズを含む第２のアドレスマップを生成する第２のアドレスマップ生成手段と、
前記第２のアドレスマップに基づいて前記再生単位を前記録媒体から読出すストリーム制御手段と、
前記ストリーム制御手段によって前記記録媒体から読み出された前記再生単位を復号するデコード制御手段とを備えたものである。
【発明の効果】
【０００９】
この発明に係る映像音声再生装置は、
通常速度で再生する場合、及び、早送り再生の場合などの再生条件に応じて、最適なアドレスマップを作成し、直接参照することができるので、読出し処理が早くなり、映像音声 の表示が途切れることなく、滑らかに表示することができる。
特に、早送り再生など通常再生より高速なストリームの読み出しを行う特殊再生において、特殊再生に必要とされるピクチャデータの読出しが遅れることなく、スムーズな特殊再生の映像を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】この発明の実施の形態１による映像音声再生装置の構成を示すブロック図である。
【図２】この発明の実施の形態１におけるアドレスマップの構成を示したテーブルである。
【図３】この発明の実施の形態１における第２のアドレスマップの構成を示したテーブルである。
【図４】この発明の実施の形態１における任意の位置からの再生実行の説明図である。
【図５】この発明の実施の形態１における通常再生のシーケンスを示す説明図である。
【図６】この発明の実施の形態１における比較のための早送り再生のシーケンスを示す説明図である。
【図７】この発明の実施の形態１における比較のための早送り再生の場合のフローチャートである。
【図８】この発明の実施の形態１における早送り再生のシーケンスを示す説明図である。
【図９】この発明の実施の形態１における早送り再生の場合のフローチャートである。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１は、この発明を実施するための実施の形態１における映像音声再生装置１００の構成を示すブロック図である。映像音声再生装置１００は、ユーザーの操作を受け付けるリモコン（図示せず）からの赤外信号を受け付けるリモコン受信部２と、ユーザーに対してシステムの状態を提示するとともに、ユーザー操作に対応した反応を返すＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）部１と、圧縮符号化した映像音声情報であるストリームを記録する記録メディア１２と、圧縮符号化されたストリームを復号化するデコーダ１４と、デコーダ１４に対してストリームを安定的に記録するためのストリームバッファ１３と、記録メディア１２から読み出したストリームをストリームバッファ１３に転送するとともに、デコーダを制御する再生制御部３と、デコーダ１４で復号化された映像音声信号を出力するモニター出力端子１５とから構成されている。また、モニター出力端子１５から出力される映像および音声信号は、モニター２１によって、ユーザーに映像および音声として提示される。再生を行う再生制御部３は、記録メディアから再生対象となるストリームを読み出し、ストリームバッファに一次的に書き込むとともに、ストリームバッファ１３に書き込まれたストリームをデコーダ１４に対してＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送を行うストリーム制御部６と、デコーダ１４に対して、デコードの開始終了指示、デコード対象とするピクチャの制御、デコード開始条件や、デコード終了条件を指示するデコーダ制御部７とを有する。
【００１２】
さらに、映像音声再生装置１００は、記録されているストリームのアクセス単位となる各ＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）やフレームの再生開始時刻、位置情報（アドレス）およびサイズが記録されているアドレスマップ１１と、アドレスマップ１１の情報を元に、再生する時間情報もしくは再生対象となるデータのアドレス位置から、一致するＧＯＰもしくはＩピクチャの情報を提供するアドレス管理部５と、ストリーム制御部８に対して、アドレスマップ１１の情報を元に、次に再生することが予定されているデータに関するＧＯＰもしくはＩピクチャの位置やサイズが記録される第２のアドレスマップを生成する第２のアドレスマップ生成部８とを有する。
【００１３】
ここでアドレスマップ１１とは記録されているストリームの各ＧＯＰの再生時刻情報に加えて、各ＧＯＰのストリーム先頭からのオフセット位置を示すアドレスおよびサイズ、また各ＧＯＰ内に含まれるキーフレームである各ＩピクチャやＢピクチャ、Ｐピクチャなどのアクセス単位のストリームの先頭からのオフセット位置を示すアドレス情報およびサイズが記録されているデータベースである。
【００１４】
アドレスマップ１１は、例えば記録メディア１２が、Ｂｌｕ−ｒａｙディスクやＤＶＤディスクなどの光ディスクの場合は、その光ディスクの管理領域に記録さている。また、記録メディア１２が、ハードディスクなどの記憶装置である場合は、映像音声情報と同じ記憶装置内の所定に位置に記録されている。
【００１５】
次に、映像音声再生装置１００の再生手順について説明する。ユーザーが記録メディア１２に記録さている映画などの任意のコンテンツの再生を要求すると、ＧＵＩ部１から再生制御部３に対してコンテンツを示すＩＤで再生要求が行われる。再生制御部３内の再生動作処理部４は、再生要求されたコンテンツＩＤに対応するアドレスマップを記録メディア１２から読出し、アドレスマップ１１に展開する。次に再生動作処理部４は、再生を要求されたコンテンツが再生の中断位置を示す情報（レジューム情報）を有すれば、レジューム情報が示す時間を再生開始時間とする。一方で、再生動作処理部４は、レジューム情報が存在しない場合であれば、再生開始時間を０秒に設定する。次いで、再生動作処理部４は、再生開始時間に対応するアドレス位置をアドレス管理部５に問い合わせ、アドレス管理部５は、アドレスマップ１１を用いて、ストリームの再生開始アドレスを導出する。再生動作処理部４は、通常速度の再生（以下、通常再生）の場合、アドレス管理部５が求めたストリームの再生開始アドレスや再生終了アドレスからなる第２のアドレスマップを生成し、第２のアドレスマップとともに、再生の指示をストリーム制御部６に送る。ストリーム制御部６は、再生動作処理部４から送られた第２のアドレスマップに記載された読み出すべきストリームの情報である再生開始アドレスおよび再生終了アドレスを元に、記録メディア１２から再生開始アドレスを先頭にストリームを読み出し、ストリームバッファ１３に書込みを行う。さらにストリーム制御部６は、ストリームバッファ１３に対してＤＭＡ転送機能によって書き込んだストリームをデコーダ１４に対して転送を行うように指示する。デコーダ制御部７は、再生開始とともに、再生状態に合わせてデコーダ１４の制御を行う。例えば、通常再生であれば、ストリームの先頭時刻からＩ、Ｐ、Ｂ全てのピクチャをデコードし、１フレームを１フレーム時間でデコードするように制御を行う。デコーダ１４でデコードされた映像音声情報はモニター出力端子１５からモニター２１に出力を行う
【００１６】
ユーザーが再生停止要求を行うと、ＧＵＩ部１から再生制御部３の再生動作処理部４に対して、再生停止要求が通知される。するとストリーム制御部６は、記録メディア１２からストリームを読み出す処理を中止するとともに、ストリームバッファ１３に対してＤＭＡ転送の中止制御を行う。またデコーダ制御部７は、デコーダ１４に対してデコード停止制御を行う。
【００１７】
次に、アドレスマップ１１について説明する。図２は、本実施の形態におけるアドレスマップの構成を示したテーブルである。映像音声データのストリームが、ＭＰＥＧ−２の場合、ＧＯＰ単位で符号化は行われ、ＧＯＰ内の先頭にＧＯＰに唯一、ピクチャ内で符号化されるＩピクチャが存在する。よって、ストリーム上の再生開始位置であるエントリーとしてＩピクチャの先頭、もしくはＧＯＰの先頭を指定するものとする。もし、Ｉピクチャ、もしくはＧＯＰの先頭から再生を行わない場合、再生開始ピクチャの復号化が正しく行われず、再生開始映像が乱れた映像でスタートする場合がある。そのため、Ｉピクチャの先頭、もしくはＧＯＰの先頭位置から再生を開始することが非常に重要になる。さて、アドレスマップ１１には、図２に示すように各ＧＯＰに対してＧＯＰおよびＩピクチャに対する再生時刻情報と、ストリーム先頭からの相対アドレス位置（以降アドレス情報）およびサイズ情報が記載されている。再生時刻情報は、ストリーム先頭から通常速度で再生した場合において、当該ＧＯＰの再生が開始される時刻である再生経過時間を示しており、本実施の形態では、１秒あたり４５ｋＨｚのクロックで計数するものとしている。なお、図２の再生時刻情報は、再生開始時刻を示しているが、必ずしも再生開始時刻である必要はなく、例えば再生終了時刻でもよい。
【００１８】
アドレス管理部５は、このアドレスマップ１１を利用して、任意の再生時刻から、対応するＧＯＰもしくはＩピクチャのアドレス位置を割り出すことができる。また、逆に現在の再生しているデータのアドレスから、対応するデータの再生時刻情報を求めることができる。
【００１９】
次に、アドレスマップ１１を元に、第２のアドレスマップ生成部８が生成する第２のアドレスマップについて説明する。図３は、本実施の形態における第２のアドレスマップの構成を示したテーブルである。図３（ａ）は、ストリーム全体を通常速度で再生する場合の第２のアドレスマップの例である。通常速度の場合は、第２のアドレスマップは、ストリームの先頭のＧＯＰと終端のＧＯＰとの再生時刻情報、各ＧＯＰの先頭アドレスおよび各ＧＯＰのサイズから構成される。この第２のアドレスマップを受信したストリーム制御部６は、先頭のＧＯＰから順次ストリームを読み出し、終了位置である７１９９ＧＯＰ目まで順次ストリーム読み出す。
【００２０】
図３（ｂ）は、ストリームの特定区間を指定して再生を行う場合の第２のアドレスマップの例である。この例では、１０分から２０分までの再生時刻区間を再生するものとしている。第２のアドレスマップに記載される情報は、先頭である１２００ＧＯＰ、および終了位置である２４００ＧＯＰの再生時刻情報と、各ＧＯＰの先頭アドレスおよび各ＧＯＰのサイズから構成される。この第２のアドレスマップを受信したストリーム制御部６は、１２００ＧＯＰのＧＯＰ先頭アドレスで記載される位置からストリームを読み出し、２４００ＧＯＰのＧＯＰ先頭アドレスで記載されるＧＯＰを最終として、順次ストリームを読み出す。
【００２１】
図３（ｃ）は、早送り再生における第２のアドレスマップの例である。ここでは、ストリームの先頭から１０分の位置から早送り再生する場合について示す。早送りの速度は、１０秒に１つのＧＯＰを表示する仕様としている。早送り再生では、Ｉピクチャのみを表示するため、第２のアドレスマップに記載されるのは、表示される２０ＧＯＰ毎の再生時刻情報、各ＧＯＰに含まれるＩピクチャの先頭アドレスおよびＩピクチャのサイズから構成される。この第２のアドレスマップを再生動作処理部４を経由して受信したストリーム制御部６は、第２のアドレスマップに記載された先頭のＧＯＰから順に、各Ｉピクチャの先頭アドレスからサイズに記載されたデータをストリームから読み出していく処理を１０回繰り返す。ここでは、一回に送る第２のアドレスマップに記載されるＩピクチャのデータ数は１０と決めているため、１０個のＩピクチャの読み出しが終わった時点、もしくはその前に、第２のアドレスマップ生成部８は次の第２のアドレスマップを生成し、この第２のアドレスマップが再度ストリーム制御部６に送られる。この処理を繰り返すことによって、早送り再生が継続して実行される。なお、上記、第２のアドレスマップに記載されるＩピクチャの数を１０個としているが、この数に制約されるものではない。また、再生状態や再生速度やシステムの負荷状況に合わせて、個数を適応的に変更してもよい。
【００２２】
次に、第２のアドレスマップを用いて、任意の位置から再生を実行する場合の処理について説明する。図４は、本実施の形態における任意の位置からの再生を実行する場合の説明図である。図４（ａ）は、アドレス情報を順次読み出すことにより任意の位置から通常再生を実行するときの説明図である。タイムサーチなど、任意の時間を指定して再生を行う場合等において、再生動作処理部４に対して再生時刻が指定されると、再生動作処理部４は、アドレス管理部５に対して再生開始時刻を元にアドレス情報の問い合わせを行う。アドレス管理部５は、アドレスマップ１１を元に、指定された再生開始時刻に対応するアドレス情報を再生動作処理部４に返す。再生動作処理部４は、ストリーム制御部６にアドレス情報を渡す。ストリーム制御部６は、記録メディア１２から指定されたアドレスに対応するデータを読み出し、ストリームバッファ１３に書込みを行う。続いて再生を実行する場合は、再生動作処理部４は、アドレス管理部５に対して、先の再生開始時間から１つ進めた時間を対応するアドレス情報を取得して、再度ストリーム制御部６にアドレスを再度渡すことによって、連続したストリームの再生を行うことができる。なお、通常再生の場合は、上述のように再生動作処理部４に順次アドレス情報を受け渡すことなく、ストリーム制御部６が最初に取得したアドレスから継続的に記録メディア１２からストリームを読み出すことによって、再生を継続することもできる。
【００２３】
ところが、早送りや早巻戻し再生など、時間方向にある程度の間隔を空けて再生を行う場合、再生動作処理部４が、次の再生単位の時間位置を指定して再生を行わなければならない。例えば、４５００００（１０秒）、９０００００（２０秒）、１３５０００（３０秒）、・・・のように１０秒間隔のＩピクチャを離散的に記録メディア１２から読出し、再生を行う場合、アドレスマップで再生開始時刻からアドレス情報を取得して、記録メディア１２から対応するストリームを取得して、ストリームバッファ１３に書込み、デコードを行う一連の動作を高速に繰り返していく必要がある。つまり、再生制御部３の各部が連携し、かつ高速に動作を繰り返す必要があるため、例えば、アドレス情報の取得が遅れた場合、記録メディア１２からのストリームの読み出しも遅延し、デコーダにストリームが転送されない場合が発生し、結果として映像がスムーズに再生されない不具合を生じる可能性がある。
【００２４】
図４（ｂ）は、１回で複数個分のアドレス情報を読み出すことにより任意の位置からはや送り再生を実行するときの説明図である。図４（ｂ）に示すように、早送り再生などにおいて、一度に大量のＩピクチャのデコード処理を行わなければならない場合、再生動作処理部４は、一度に複数のＩピクチャに対応するアドレス情報を取得するとともに、第２のアドレスマップ生成部８で、早送り再生で必要となるＩピクチャの位置およびサイズからなる第２のアドレスマップを生成し、生成した第２のアドレスマップ８をストリーム制御部６に送り込む。ストリーム制御部６は、ストリームバッファ１３の空き状況を見ながら、自らの速度で記録メディア１２からの読み出しを行い、結果として、切れ目のないスムーズな再生を行うものである。
【００２５】
この場合、再生動作処理部４からストリーム制御部６へは、第２のアドレスマップによって、１つの命令で１０個のアドレス情報を渡すことができるので、１回に１度ずつアドレス情報を渡す場合に比べて、１０分の１の負荷でアドレス情報をストリーム制御部６に渡すことができる。また、ストリーム制御部６は、一度に１０個の再生すべきストリームのアドレス情報を一度に取得できるので、読み出しごとにアドレス情報の到着を待つことなく、デコードおよびストリームバッファ１３の空き状況のみを確認しながら記録メディア１２からストリームの読み出しを行うことが可能となる。その結果、早送り画像の間隔に切れ目や、表示ピクチャの表示時間にばらつきが発生することを回避することができる。さらには、早送り再生で必要となるＩピクチャの情報のみが転送されるので、早送り再生に不要なＧＯＰ中のＩピクチャ以外のピクチャについてストリーム制御部６で考慮する必要がない。
【００２６】
次に、図５のシーケンス図を用いて、再生の基本処理について説明する。図５は、本実施の形態における通常再生のシーケンスを示す説明図である。ＧＵＩ部１が再生動作処理部４に対して再生要求を行うと(Ｓ１０１)、再生動作処理部４は、デコーダ制御部７に対して、デコード開始処理を要求する（Ｓ１０２）。さらに再生動作処理部４は、アドレス管理部５から再生開始時刻に対応するアドレス情報を取得する（Ｓ１０３）。通常再生においては、再生対象とする先頭ＧＯＰおよび終端のＧＯＰの先頭アドレスと、各ＧＯＰのデータサイズを取得する。これを元に、ストリーム制御部６に伝えるべき第２のアドレスマップを第２のアドレスマップ生成部８で生成する。第２のアドレスマップの例は、図３（ａ）で示したとおりである。
【００２７】
次に、再生動作処理部４は、ストリーム制御部６に対して、第２のアドレスマップを伝えるとともに、対応するストリームの読み出しと、ストリームバッファ１３への転送を指示する（Ｓ１０５）。ここで、再生動作処理部４とストリーム制御部６は、それぞれ独立したタスクと呼ばれる独立した資源と動作単位で構成されるプログラム単位で構成されるものとし、タスク間の要求は、メッセージと呼ばれるデータの送受信を行うことによって、成立するものとする。また、メッセージを受け付ける箱をメッセージキューとする。メッセージは、メッセージキューを介して送受信が行われるために、送信側と受信側は、任意のタイミングでメッセージキューを参照すればよく、そのために、お互いにメッセージのやり取りに関して、互いの送受信を確認するような待ち動作は必要がない。しかしながら、メッセージキューの数の限度や互いの状態の確認があるため、完全に独立した動作を保障するものではない。ここでは、再生動作処理部４から、ストリーム制御部６への命令はメッセージをつかった非同期通信で行われるものとする。第２のアドレスマップとストリームの読み出しおよび転送指示とを受け取ったストリーム制御部６は、記録メディア１２から対応するＧＯＰを読み出す（Ｓ１０６）とともに、読み出したＧＯＰをストリームバッファ１３へ書込みを行う（Ｓ１０７）。さらにデコード制御部７は、ストリームバッファ１３に書き込まれたＧＯＰをデコーダ１４へＤＭＡ転送するように、図示しないがＤＭＡコントローラにＤＭＡ転送の開始を指示する。デコード制御部７の制御下にあるデコーダ１４は、ＤＭＡ転送されてきたＧＯＰのデコード処理を行う（Ｓ１０８）。通常再生の場合は、第２のアドレスマップで伝えられた区間を先頭のデータから順に再生することによって、全ての区間の再生を行うことができる。
【００２８】
なお、通常再生の場合において、第２のアドレスマップを生成することなく、ＧＯＰ毎のアドレスとサイズ情報とをＳ１０５のステップでストリーム制御部６に送る方法もある。この場合、再生動作処理部４で行うＧＯＰのアドレスとサイズ情報との取得が完了するごとに、ストリーム制御部６に向け１つの通信が行われるが、データの転送頻度が１ＧＯＰ＝０．５秒の標準的な構成の場合、０．５秒に一度のメッセージコマンドの送信で済むので、ＣＰＵの処理負荷が問題になることはない。
【００２９】
次に、図６のシーケンス図を用いて、比較のために第２のアドレスマップを生成せずに、早送り再生を行う処理について説明する。図６は、早送り再生のシーケンスを示す説明図である。ＧＵＩ部１が再生動作処理部４に対して再生要求を行うと(Ｓ２０１)、再生動作処理部４は、デコーダ制御部７に対して、Ｉピクチャのみを復号化することを指示するデコード開始処理を要求する（Ｓ２０２）。さらに再生動作処理部４は、アドレス管理部５から再生開始時刻に対応するアドレス情報を取得する（Ｓ２０３）。早送り再生においては、再生対象とするＩピクチャの先頭アドレスと、Ｉピクチャのデータサイズとを取得する。早送り再生では、再生動作処理部４は、ストリーム制御部６に対して、高速にＩピクチャの先頭アドレスとサイズとを伝える必要があるが、送信するメッセージバッファがメッセージコマンドであふれる可能性があるため、あらかじめメッセージキューの空き状態を確認する（Ｓ２０４）。次に、再生動作処理部４は、ストリーム制御部６に対して、取得したＩピクチャのアドレス情報とサイズ情報とを伝えるとともに、対応するストリームの読出しと、ストリームバッファ１３への転送を指示する（Ｓ２０５）。アドレス情報を取得したストリーム制御部６は、記録メディア１２から対応するＩピクチャを読み出す（Ｓ２０６）とともに、読み出したＩピクチャをストリームバッファ１３へ書込みを行う（Ｓ２０７）。さらにデコード制御部７は、ストリームバッファ１３に書き込まれたＩピクチャをデコーダ１４へＤＭＡ転送するように、図示しないがＤＭＡコントローラにＤＭＡ転送の開始を指示する。デコード制御部７の制御下にあるデコーダ１４は、ＤＭＡ転送されてきたＩピクチャのデコード処理を行う（Ｓ２０８）。
【００３０】
ところで、再生動作処理部４は、ストリーム制御部６に対してＩピクチャの読み出しを指示した（Ｓ２０５）後は、次のＩピクチャのアドレス情報とサイズ情報とをアドレス管理部５から取得し（Ｓ２０９）、メッセージコマンドの送信のためのメッセージキューの空き確認し（Ｓ２１０）、さらに次のＩピクチャの読み出し指示をストリーム制御部６に送る（Ｓ２１１）。また、ストリーム制御部６は、先行しているＳ２０６、Ｓ２０７の処理が終われば、次に送られてきたＩピクチャの読み出しと（Ｓ２１２）、ストリームバッファへの転送と（Ｓ２１３）を実行する。また、デコーダ１４も、対応するＩピクチャのデコード処理を実行する（Ｓ２１４）。
【００３１】
上記の早送り再生において、再生動作処理部４とストリーム制御部６とは、メッセージコマンドを使って制御命令の授受を行っているが、頻繁にメッセージを送信することは、ＣＰＵの負荷が大きくなり、実装されている機能動作が十分に動作しない状況に陥る場合がある。また、メッセージキューの空きを待つ処理（Ｓ２０４、Ｓ２１０）によって、メッセージキューの空き待ち状態に陥ると、再生動作処理部４は次のＩピクチャのアドレス情報やサイズ情報の読み出しを行なうことができない。このことは、再生動作処理部４とストリーム制御部６との動作が、一方で生成された遅延によって、他方が待ち状態に陥り、ソフトウェアのスムーズな動作を阻害し、結果として表示される映像や出力される音声がなめらかに表示されない問題を引き起こすこととなる。
【００３２】
さらに、図７のフローチャートを用いて、比較のために第２のアドレスマップを生成せずに、早送り再生を行う場合の再生動作処理部４の動作と、ストリーム制御部６の動作とを説明する。図７は、早送り再生の場合の再生動作処理部の動作と（図７の左）、ストリーム制御部の動作と（図７の右）のフローチャートである。
【００３３】
再生動作処理部４が早送り（Ｓ３０１）状態になると、早送りの解除要求の有無を確認し（Ｓ３０２）、終了の条件を満たす要求があれば早送りを終了する（Ｓ３０９）。解除要求がなければ、最新の再生時刻情報を確認する（Ｓ３０３）。最新の再生時刻情報とは、早送りが開始された直後であれば、早送り再生を開始する前の再生時刻であり、もし早送り再生中であれば、現在再生を行っている時刻情報である。次に最新の再生時刻情報から、次の再生すべき時刻位置を決定する（Ｓ３０４）。例えば、早送り再生として、１０秒毎に１枚のＩピクチャを再生することが規定されていれば、最新の再生時刻情報に１０秒に相当する４５００００を加算した値を算出する。次いで、アドレス管理部５が管理するアドレスマップより、算出した次の再生時刻に対応するＩピクチャのアドレスとサイズを取得する（Ｓ３０５）。このときファイル終端か否かを確認し（Ｓ３０６）、ファイル終端であれば、早送り再生を中断する。終端でなければ、ストリーム制御部６にメッセージを送るためのメッセージキューの空きサイズを確認し（Ｓ３０７）、空きがなければ空きを待つ。空きが発生すれば、ストリーム制御部６に対して、ストリームの転送とデコード要求を発行するとともに、再生すべきＩピクチャのアドレスとサイズを送信する。さらに再生動作処理部４は、Ｓ３０２に戻り、上記の動作を継続的に続ける。
【００３４】
一方、早送り再生が開始されると、ストリーム制御部６は、Ｉピクチャのみの再生動作を開始する（Ｓ３１１）。まず、Ｉピクチャ再生状態の終了指示があるかないかを確認し（Ｓ３１２）、再生終了の指示があれば、Ｉピクチャの再生を終了する（Ｓ３１７）。Ｉピクチャの再生終了指示がなければ、再生動作処理部４からのメッセージがメッセージキューに入っているか否かを確認する（Ｓ３１３）。メッセージキューにメッセージがなければ、メッセージキューにメッセージが送り込まれるまで待機する。メッセージを受信すると、受け取ったＩピクチャのアドレスとサイズ情報を元に、記録メディア１２からＩピクチャを読みだし（Ｓ３１４）、ストリームバッファ１３に書込みを行う（Ｓ３１５）。次いでデコーダ１４がＩピクチャのデコードを行う（Ｓ３１６）。続いて、Ｓ３１２に戻り、再生動作処理部４からの次のＩピクチャ再生要求のメッセージを待機する。
【００３５】
上述のような早送り再生の動作においては、ひとつのＩピクチャに関する情報をアドレスマップから読み出す毎に、メッセージを使ったＩピクチャ情報の送信処理が行われるので、送受信にかかるＯＳの負荷が高くなる。またメッセージ送信によって、動作するタスクが切り替わるために、タスクスイッチによる余分なシステム負荷や、システム負荷増による処理時間の遅延が発生する。また、ストリーム制御部６は、高速にストリームの転送を行うため、また他の処理に比べて安定的に動作するようにタスクの優先度を高めているため、高速にＳ３１２からＳ３１６の処理を実行する場合が多い。一方で再生動作処理部４は、それほど優先度が高く設定されていない。つまり、再生動作処理部４は、ストリーム制御部６に比べ処理が遅延する可能性があり、結果的にストリーム制御部６が再生すべきＩピクチャの情報受け取り待ち状態に陥り、結果としてＩピクチャを連続的にストリームバッファ１３に供給できないために、Ｉピクチャを連続的に再生できない。
【００３６】
次に、本実施の形態の第２のアドレスマップを使って、再生動作処理部４とストリーム制御部６との間で複数のＩピクチャのデータを送る場合について説明する。図８は、本実施の形態における第２のアドレスマップを用いたときの早送り再生のシーケンスを示す説明図である。
【００３７】
ＧＵＩ部１が再生動作処理部４に対して再生要求を行うと(Ｓ４０１)、再生動作処理部４は、デコーダ制御部７に対して、Ｉピクチャのみを復号化することを指示するデコード開始処理を要求する（Ｓ４０２）。次に、再生動作処理部４は、アドレス管理部５から次の再生開始時刻を先頭に、１０個分の再生位置に対応するアドレス情報を取得する（Ｓ４０３）。さらに、１０個分のＩピクチャのアドレス情報およびサイズ情報からなる第２のアドレスマップを、第２のアドレスマップ生成部で生成する（Ｓ４０４）。次に、メッセージキューの空き状態を確認する（Ｓ４０５）。次いで、再生動作処理部４は、ストリーム制御部６に対して、取得したＩピクチャ１０個分のアドレス情報とサイズ情報とからなる第２のアドレスマップを送信するとともに、対応するストリームの読み出しと、ストリームバッファ１３への転送とを指示する（Ｓ４０６）。
【００３８】
第２のアドレスマップを取得したストリーム制御部６は、記録メディア１２から対応するＩピクチャを読み出す（Ｓ４０７）とともに、読み出したＩピクチャをストリームバッファ１３へ書き込みを行う（Ｓ４０８）。さらにデコード制御部７は、ストリームバッファ１３に書き込まれたＩピクチャをデコーダ１４へＤＭＡ転送するように、図示しないがＤＭＡコントローラにＤＭＡ転送の開始を指示する（Ｓ４０９）。ここで、ストリーム制御部６は、処理できるＩピクチャの情報をまだ９個分所有しているために、次のＩピクチャに関するストリームの読出し（Ｓ４１０）と、読出したストリームをストリームバッファに書き込む処理とを行う（Ｓ４１１）。次いで、デコーダ制御部７は、転送したストリームのデコード処理を行う（Ｓ４１２）。この動作は、送られたＩピクチャの数である１０個分連続して動作させることができる（Ｓ４１３、Ｓ４１４、Ｓ４１５）。
【００３９】
一方で、再生動作処理部４は、ストリーム制御部６がストリームの転送処理、もしくはデコーダ制御部７がデコード処理を実行しているのと並行して、次のＩピクチャ１０個分の開始位置のアドレス情報を取得する（Ｓ４２１）。さらに、１０個分のＩピクチャのアドレス情報とサイズ情報とからなる第２のアドレスマップ生成部で、第２のアドレスマップを生成する（Ｓ４２２）。再生動作制御部４は、メッセージキューが空くのを待って（Ｓ４２３）、次のＩピクチャ１０個分のアドレス情報とサイズ情報とが記載された第２のアドレスマップをストリーム制御部６に送るとともに、ストリームの読出し指示を行う（Ｓ４２４）。
【００４０】
上述の構成のように、再生動作処理部４においてストリーム制御部６で必要な情報のみで構成される第２のアドレスマップを生成し、送信することによって、再生動作処理部４からストリーム制御部６へのメッセージ送信の回数を削減することができる。また、Ｉピクチャの情報をまとめて１０個読み出す処理や、ストリーム制御部６もＩピクチャのストリーム読み出しとストリームバッファへの書き込み、およびデコード処理の１０回分を、それぞれ独立に連続して行うことで、互いの処理の完了を待つことがほとんどなくなり、再生動作処理部４の動作とストリーム制御部６の動作とを独立して動作させることができる。これによって、映像および音声出力が非常にスムーズに行うことができる。
【００４１】
さらに、図９のフローチャートを用いて、第２のアドレスマップを用いて早送り再生を行う場合の再生動作処理部４の動作と、ストリーム制御部６の動作とを説明する。図９は、第２のアドレスマップを用いて早送り再生の場合の再生動作処理部の動作と（図９の左）、ストリーム制御部の動作と（図９の右）のフローチャートである。
【００４２】
再生動作処理部４が早送り（Ｓ５０１）状態になると、早送りの解除要求の有無を確認し（Ｓ５０２）、終了の条件を満たす要求があれば早送りを終了する（Ｓ５０９）。解除要求がなければ、最新の再生時刻情報を確認する（Ｓ５０３）。最新の再生時刻情報とは、早送りが開始された直後であれば、早送り再生を開始する前の再生時刻であり、もし早送り再生中であれば、現在再生を行っている時刻情報である。次に最新の再生時刻情報から、次の再生すべき時刻位置を決定する（Ｓ５０４）。例えば、早送り再生として、１０秒毎に１枚のＩピクチャを再生することが規定されていれば、最新の再生時刻情報に１０秒に相当する４５００００を加算した値を先頭に、４５００００刻みで１０個分のＩピクチャの再生時刻を算出する。次いで、アドレス管理部５が管理するアドレスマップより、算出した１０個分の再生時刻に対応するＩピクチャのアドレスとサイズとを取得する（Ｓ５０５）。さらに第２のアドレスマップ生成部８で、取得した１０個分のＩピクチャのアドレスとサイズからなる第２のアドレスマップを生成する（Ｓ５０６）。次いで、ファイル終端か否かを確認し（Ｓ５０７）、ファイル終端であれば、早送り再生を中断する。終端でなければ、ストリーム制御部６にメッセージを送るためのメッセージキューの空きサイズを確認し（Ｓ５０８）、空きがなければ空きを待つ。空きが発生すれば、ストリーム制御部６に対して、ストリームの転送とデコード要求を発行するとともに、再生すべき１０個分のＩピクチャのアドレスとサイズとが記述された第２のアドレスマップを送信する（Ｓ５０９）。さらに再生動作処理部４は、Ｓ５０２に戻り、上記の動作を継続的に続ける。
【００４３】
一方、早送り再生が開始されると、ストリーム制御部６は、Ｉピクチャのみの再生動作を開始する（Ｓ５２１）。まず、Ｉピクチャ再生状態の終了指示があるかないかを確認し（Ｓ５１２）、再生終了の指示があれば、Ｉピクチャの再生を終了する（Ｓ５１８）。Ｉピクチャの再生終了指示がなければ、再生動作処理部４からのメッセージがメッセージキューに入っているか否かを確認する（Ｓ５１３）。メッセージキューにメッセージがなければ、メッセージキューにメッセージが送り込まれるまで待機する。メッセージを受信すると、まだ再生していないＩピクチャの有無を確認し（Ｓ５１４）、未処理のＩピクチャがあれば、受け取った１０個分のＩピクチャのアドレス情報とサイズ情報との先頭から順に、記録メディア１２からＩピクチャを読みだし（Ｓ５１５）、ストリームバッファ１３に書込みを行う（Ｓ５１６）。次いでデコーダ１４がＩピクチャのデコードを行う（Ｓ５１７）。次に、再度未処理のＩピクチャの数を確認し（Ｓ５１４）、未処理があれば再度Ｓ５１５を、なければＳ５１２に戻る。
【００４４】
図８において、再生動作処理部４とストリーム制御部６との間のメッセージの授受は、第２のアドレスマップを用いない早送り再生のときの図６の場合に比べ、１／１０に減少する。そのため、タスク間を跨るメッセージの生成に要するシステムの負荷を１／１０に低減することができ、それによって、システム負荷が高いことに起因する再生画像の乱れや、出力音声の途切れなどを解消することができる。
【００４５】
一般的に、タスク間を跨るメッセージの送受信によって、動作するタスクの切り替えが発生する。また、タスク切り替えは、動作するタスクと停止するタスクとのリソース切り替え処理が必要とされており、タスク切り替えに要するオーバーヘッドが問題視される。本実施の形態のように第２のアドレスマップを用いたメッセージ処理の低減は、動作するタスクの頻繁な変更を低減することができ、結果的には、システム負荷の低減や、再生画の乱れや、出力音声の途切れなどを解消することができる。
【００４６】
上述のように、本実施の形態による映像音声再生装置によれば、ストリーム制御部で使用するストリームのデータを第２のアドレスマップとして生成するので、ストリーム制御部では、第２のアドレスマップを直接参照すればよく、非常に簡潔な構成とすることができる。
【００４７】
例えば、通常再生であればＧＯＰ全体を読み出すことが必要であり、一方で早送り再生であればＩピクチャのみを読み出すことが必要であり、従来であれば、この区別を行う機構をストリーム制御部に実装する必要があった。本実施の形態のように、第２のアドレスマップ生成部を備えることで、この第２のアドレスマップ生成部でストリーム制御部が参照する専用の第２のアドレスマップを生成しているので、第２のアドレスマップにストリーム制御部が読み出すべきデータのみ、状況に応じて必要なデータのみを記載することによって、ストリーム制御部はＧＯＰやＩピクチャを意識することなく読み出すことができる。
【００４８】
例えば、通常再生であればＧＯＰ全体を読み出すように、先頭アドレスやサイズを指定する。一方で、早送り再生のときは各Ｉピクチャの先頭アドレスとサイズとを第２のアドレスマップに記載するだけで、ストリーム制御部は、データの形式を考慮することなく、ストリームの読み出しを行うことができる。さらに、少し早めの再生（例えば、１．５倍速再生）として、先頭のＩピクチャ、Ｐピクチャ、およびＢピクチャを含む３つのピクチャを再生したい場合、前期３つのピクチャの先頭のピクチャの先頭のアドレスと、３つのピクチャを含んだストリームの範囲をサイズとして、第２のアドレスマップに記載し、ストリーム制御部に送ることによって、ストリーム制御部は、３つのピクチャの種類やタイプ、また再生速度を意識することなく、ストリームの読み出しや転送に専念することができる。つまり、ストリーム制御部が、アドレスマップを読み出す処理を実装しなくてよいいため、ストリーム制御部本来のストリームを読み出して、デコーダに送り出す処理のみを実装すればよく、実装量の削減と複雑度の低減、不具合の低減が可能となる。結果として、少し早めの再生を簡単な構成で実現することができる。また、ストリーム制御部が、アドレスマップを読み出す処理を実装しなくてもよいため、ストリーム制御部本来の、ストリームを読み出してデコーダに送り出す処理の機構のみを実装すればよく、実装量の削減と複雑度の低減、不具合の低減が可能となる。
【００４９】
なお、第２のアドレスマップに記載するデータの単位は、必ずしもＧＯＰ単位である必要がなく、通常再生であれば、アドレスとして先頭位置を示すデータ、サイズとしてファイル全体を示すデータの２つのみであってもよい。つまり、再生を行いたい単位を直接指定することが可能であり、ストリーム制御部は、再生状態等を勘案することなく、指定された位置を順に読み出すだけで再生が可能であり、非常に簡潔な制御が可能となる。
【００５０】
また、ストリーム制御部は、システムの再生状態に応じて本来のアドレスマップから読み出すべきデータを選定する処理、読み出すべき時間に対応するデータを探し出す処理、およびデータを読み出す処理が必要でなくなる。そのため、ストリーム制御部の読出し処理が早くなり、映像音声の表示が途切れることなく、滑らかに表示ができる。
【００５１】
また、早送り再生の速度は、第２のアドレスマップに記載するＩピクチャのスキップ幅だけを制御すればよく、ストリーム制御部が早送り再生の速度を考慮する必要がない。すなわち、ストリーム制御部の実装量の削減と不具合発生量の低減を行うことができる。
【００５２】
また、一度に複数の読み出し位置の情報を送ることができるので、読み出し単位毎に送る方法に比べて、システム負荷が軽く、結果として滑らから映像音声再生を実現できる。
【００５３】
また、再生状態を管理しているタスクから、ストリームの読み出しを管理するタスクを跨って、複数の読出し位置の情報を一度に送ることができるので、毎回メッセージを生成する場合に比べて、メッセージの生成に要する負荷を低減できる。
【００５４】
また、メッセージ送信によって発生するタスクの切り替わり回数についても、メッセージ送信の回数が減ることによって、減少し、タスク切り替えによって生じるシステムのオーバーヘッド負荷を低減することができる。
【００５５】
さらには、生成する第２のアドレスマップは、ストリーム制御部の動作に対して最適化することができ、メディアフォーマットに依存することがなく、自由に、かつシステム内で統一的に設計することができる。例えば、同じＳＤカードにＭＰ４のデータ形式と、ＡＶＣＨＤのデータ形式が存在していた場合においても、アドレスマップはそれぞれ別の形式を有するが、システム内で統一した第２のアドレスマップを生成することが可能となり、ストリーム制御部はメディアフォーマットの影響を受けることなく、独立した処理や制御アルゴリズムを採用することができる。その結果、各種のフォーマットに簡単に対応することができる。
【符号の説明】
【００５６】
１  ＧＵＩ部、２  リモコン受信部、３  再生制御部、４  再生動作処理部、５  アドレス管理部、６  ストリーム制御部、７  デコーダ制御部、８  第2のアドレスマップ生成部、１１  アドレスマップ、１２  記録メディア、１３  ストリームバッファ、１４  デコーダ、１５  モニター出力端子、２１  モニター
【図１】
0005589654.tif 000002
【図２】
0005589654.tif 000003
【図３】
0005589654.tif 000004
【図４】
0005589654.tif 000005
【図５】
0005589654.tif 000006
【図６】
0005589654.tif 000007
【図７】
0005589654.tif 000008
【図８】
0005589654.tif 000009
【図９】
0005589654.tif 000010