(57)【要約】【課題】プレイリストとセグメントを利用してライブストリーミングする場合に、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化する。【解決手段】複数の再生区間に分割されたメディアデータをネットワークを介して受信する受信装置であって、前記メディアデータの再生順序を示す再生区間情報と前記メディアデータとを受信する受信手段と、前記ネットワークの種類や通信状況に応じた最大遅延時間を計測する計測手段と、前記再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が前記最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を送信する制御手段とを設ける。【選択図】図２
2015041800.tif 000002
【特許請求の範囲】
【請求項１】
複数の再生区間に分割されたメディアデータをネットワークを介して受信する受信装置であって、
前記メディアデータの再生順序を示す再生区間情報と前記メディアデータとを受信する受信手段と、
前記ネットワークの種類や通信状況に応じた最大遅延時間を計測する計測手段と、
前記再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が前記最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を送信する制御手段と、
を有することを特徴とする受信装置。
【請求項２】
前記制御手段は、前記再生順序が最初のメディアデータから順に取得要求を送信することを特徴とする請求項１に記載の受信装置。
【請求項３】
前記制御手段は、未受信のメディアデータにのみ取得要求を送信することを特徴とする請求項１に記載の受信装置。
【請求項４】
前記計測手段は、無線通信回線の種類、通信速度、往復応答時間、ジッタの少なくとも１つを計測することを特徴とする請求項１に記載の受信装置。
【請求項５】
前記メディアデータは、映像データまたは音声データの少なくとも一方を含むことを特徴とする請求項１乃至３のいずれか１項に記載の受信装置。
【請求項６】
複数の再生区間に分割されたメディアデータをネットワークを介して受信する受信方法であって、
前記メディアデータの再生順序を示す再生区間情報と前記メディアデータとを受信する受信工程と、
前記ネットワークの種類や通信状況に応じた最大遅延時間を計測する計測工程と、
前記再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が前記最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を送信する制御工程と、
を有する受信方法。
【請求項７】
コンピュータを請求項１乃至５のいずれか１項に記載の受信装置の各手段として機能させるためのプログラム。
【請求項８】
複数の再生区間に分割されたメディアデータをネットワークを介して受信する受信方法をコンピュータに実行させるプログラムであって、
前記メディアデータの再生順序を示す再生区間情報と前記メディアデータとを受信する受信工程と、
前記ネットワークの種類や通信状況に応じた最大遅延時間を計測する計測工程と、
前記再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が前記最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を送信する制御工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項９】
請求項７または８に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は受信装置及び受信方法に関し、特に、メディアデータとメディアデータの再生区間情報を所定の時間毎にネットワークを介して連続して送受信するために用いて好適な技術に関する。
【背景技術】
【０００２】
近年、ネットワークカメラやビデオ会議システムなど、ネットワークを介してメディアデータをリアルタイムに送受信するストリーミング技術が実用化されている。このようなストリーミング技術の例として、プレイリストとセグメントを利用してメディアデータをストリーミングする方法が標準規格化されている。例えば、（HTTP Live Streaming（非特許文献１参照）、MPEG-DASH（非特許文献２参照）等）。
【０００３】
プレイリストとは、メディアデータの再生区間情報であり、セグメントとは所定の単位時間に分割されたメディアデータである。前述した標準規格では、プレイリストとセグメントを所定の時間毎にネットワークを介して連続して送受信することにより、メディアデータのストリーミングを可能としている。また、HTTPを使用してコンテンツをストリーミングする方法が提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−１３８０８３号公報
【非特許文献】
【０００５】
【非特許文献１】IETF draft HTTP Live Streaming draft-pantos-http-live-streaming-10
【非特許文献２】ISO/IEC 23009-1
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところが、前述した標準規格や特許文献１に記載の方法をライブストリーミングに利用する場合、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化するための具体的な方法は提案されていなかった。
本発明は前述の問題点に鑑み、プレイリストとセグメントを利用してライブストリーミングする場合に、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することを可能とすることを目標とする。
【課題を解決するための手段】
【０００７】
本発明の受信装置は、複数の再生区間に分割されたメディアデータをネットワークを介して受信する受信装置であって、前記メディアデータの再生順序を示す再生区間情報と前記メディアデータとを受信する受信手段と、前記ネットワークの種類や通信状況に応じた最大遅延時間を計測する計測手段と、前記再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が前記最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を送信する制御手段とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、プレイリストとセグメントを利用してライブストリーミングする場合に、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することができる。
【図面の簡単な説明】
【０００９】
【図１】第１の実施形態に係る送信装置と、受信装置の接続形態を示す図である。
【図２】第１の実施形態に係る受信装置の内部構成例を示すブロック図である。
【図３】第１の実施形態に係る受信装置の再生区間制御処理手順の一例を示すフローチャートである。
【図４】第１の実施形態に係る受信装置のＲＯＭに設定される最大遅延時間選択テーブルの構成を示す図である。
【図５】Ｍ３Ｕ８形式のシンプルなプレイリストの一例である。
【図６】第１の実施形態に係る送信装置と受信装置の、送受信データの関係を時間経過と共に示す図である。
【発明を実施するための形態】
【００１０】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１１】
＜第１の実施形態＞
図１は、本発明の実施形態に係る送信装置１００と、受信装置１０２の接続形態を示す図である。送信装置１００と受信装置１０２は、ネットワーク１０１を介して相互に接続されている。
【００１２】
送信装置１００と受信装置１０２は、メディアデータの再生区間情報と所定の単位時間に分割されたメディアデータとをネットワーク１０１を介して夫々連続して送受信することによりメディアデータのストリーミングを行う。以下、メディアデータの再生区間情報をプレイリストと称し、所定の単位時間に分割されたメディアデータをセグメントデータと称す。また、メディアデータは、映像データまたは音声データの少なくとも一方を含む。
【００１３】
プレイリストは、各セグメントデータの再生順序、所在情報（ＵＲＩ）、再生時間等が記載されたデータである。本実施形態では、プレイリストのフォーマットとしてテキストベースのＭ３Ｕ８形式を用いる。Ｍ３Ｕ８形式のプレイリストの詳細は、図５を用いて後述する。
【００１４】
ネットワーク１０１は、例えばホームネットワークとしての有線ＬＡＮ（Local Area Network）や無線ＬＡＮ（Wireless LAN）である。なお、本実施形態ではホームネットワークとして有線ＬＡＮや無線ＬＡＮを想定しているが、これに限らず、ＷＡＮ（Wide Area Network）、アドホックネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、ＵＷＢなどでもよい。
【００１５】
送信装置１００は、受信装置１０２からネットワーク１０１を介して送信されるプレイリスト要求・セグメントデータ要求に応じて、プレイリスト・セグメントデータの送信を行う。送信装置１００の具体的な例としては、カメラ、ビデオカメラ、スマートフォン、携帯電話、ＰＣなどが挙げられるが、後述のハードウェア構成及びモジュール構成を満たすものであれば、これらに限定されない。また、メディアデータの生成は送信装置１００内で行われてもよいし、他のサーバー装置等で生成されて送信装置１００へ送信されてもよい。
【００１６】
一方、受信装置１０２は、送信装置１００からネットワーク１０１を介して送信されるプレイリスト・セグメントデータを受信し、メディアデータの再生や記録を行う。受信装置１０２の具体的な例としては、スマートフォン、携帯電話、ＰＣ、テレビ、プロジェクターなどが挙げられるが、後述のハードウェア構成及びモジュール構成を満たすものであれば、これらに限定されない。また、ネットワーク１０１に接続された受信装置１０２は一台のみであってもよいし、複数台存在してもよい。
【００１７】
図２は、本発明の実施形態に係る受信装置１０２の内部構成の一例を示すブロック図である。
図２において、２０１は中央処理装置（ＣＰＵ）であり、以下に述べる各部を統括的に制御する。２０２はＲＡＭであり、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０３はＲＯＭであり、ＣＰＵ２０１で実行される制御プログラム等を格納している。２０４はユーザの指示を受け取る操作部であり、ボタンやモードダイヤルなどが含まれる。
【００１８】
２０５は記録部であり、通信部２１２によって受信したメディアデータを外部メモリ制御部２１０を介して記録する。２０６は各種データの転送経路となるバスである。例えば、通信部２１２によって受信したデジタルデータはこのバス２０６を介して所定の処理部に送られる。
【００１９】
２０７は表示制御部であり、表示部２０８に表示される映像の表示制御を行う。表示部２０８は、例えば、液晶ディスプレイが用いられる。表示部２０８はタッチスクリーン機能を有していてもよく、その場合はタッチスクリーンを用いたユーザ指示を操作部２０４の入力として扱うことも可能である。
【００２０】
２０９はデコーダ部であり、受信したメディアデータをＭＰＥＧ−２  ＴＳ方式にて逆多重化し、復号する処理を行う。ＭＰＥＧ−２  ＴＳは、符号化された映像や音声等のメディアデータを多重化し、伝送するためのコンテナ形式であり、本実施形態のセグメントデータとして利用する。外部メモリ制御部２１０は、ＰＣやその他のメディア（例えば、ハードディスク、メモリーカード、ＣＦカード、ＳＤカード、ＵＳＢメモリ）に繋ぐためのインターフェースである。
【００２１】
２１１は通信制御部であり、送信装置１００から受信するメディアデータや制御情報の通信制御を行う。メディアデータの受信制御処理の詳細については図３で後述する。２１２は通信部であり、送信装置１００から送信されるプレイリストやセグメントデータの受信、送信装置１００に対する制御情報の送信を行う。本実施形態の通信部２１２は、通信プロトコルとしてＨＴＴＰを用いるものとする。２１３は再生区間制御部であり、送信装置１００から送信されたプレイリストからセグメントデータの時間長やＵＲＩなどを解析し、受信するセグメントデータを制御する。
【００２２】
続いて、本実施形態の受信装置１０２によるメディアデータ受信制御の詳細について、図３を用いて説明する。図３は、本発明の実施形態に係る受信装置１０２の再生区間制御処理手順の一例を示すフローチャートである。
【００２３】
まず、通信制御部２１１は、ネットワーク１０１の無線通信回線の種類、通信速度、往復応答時間、ジッタの少なくとも１つを計測することにより、最大の遅延時間Ｔ１を計測する（Ｓ３０１）。最大遅延時間Ｔ１は、送信装置１００と受信装置１０２との間で往復の通信に要する時間の最大値である。なお、最大遅延時間Ｔ１の計測タイミングは任意であり、一定の時間間隔で定期的に計測してもよいし、ストリーミング開始時に一度だけ計測してもよい。
【００２４】
ここで、Ｓ３０１における最大遅延時間Ｔ１の算出方法は、例えば図４に示した無線通信回線の種類（３Ｇ／ＬＴＥ／Ｗｉ−Ｆｉ）と最大遅延時間とを対応付けたテーブルに基づいて決定することが可能である。本テーブルは、図２に示したＲＯＭ２０３に記録されている。
【００２５】
図４に示すように、無線通信回線の種類に応じて予め遅延時間が設定されており、無線通信回線の種類から最大遅延時間を参照することができる。また、Ｓ３０１における最大遅延時間Ｔ１の算出方法は、前述した以外にも、送信装置１００と受信装置１０２間における通信の往復応答時間とゆらぎ（ジッタ）の最大値との和を最大遅延時間Ｔ１として算出する等の方法が考えられる。
【００２６】
続いて、通信制御部２１１は、送信装置１００に対してプレイリストの取得要求を送信する（Ｓ３０２）。ここでの要求は、ＨＴＴＰ ＧＥＴメソッドを使用し、プレイリスト要求のＵＲＩが予め送信装置１００から通知されているものとする。
通信部２１２は、Ｓ３０２の要求に従い送信装置１００から送信されたプレイリストを受信する（Ｓ３０３）。
再生区間制御部２１３は、Ｓ３０１で計測した最大遅延時間Ｔ１が、Ｓ３０３で受信したプレイリストに記載の全セグメントデータの時間長Ｔ２以下か否かを判断する（Ｓ３０４）。
【００２７】
ここで、Ｍ３Ｕ８形式のプレイリストの詳細を説明する。
図５は、Ｍ３Ｕ８形式のシンプルなプレイリストの一例である。プレイリストにはセグメントデータの再生時間長、所在情報（ＵＲＩ）が記載されている。４行目の”＃ＥＸＴＩＮＦ：”タグに続く値（＝５２１９．２）がセグメントデータの秒数を、続く５行目の”ｈｔｔｐ：／／”で始まる文字列がセグメントデータのＵＲＩを示している。
【００２８】
本例では、単一のセグメントデータに関する情報のみが記載されているが、プレイリストに複数のセグメントデータに関する情報が記載される場合もある。この場合には、各セグメントデータの時間長の和を計算することにより、全セグメントデータの時間長Ｔ２を求めることが可能である。図５中の＃ＥＸＴで始まるその他のタグについての説明は省略する。
【００２９】
なお、本実施形態において送信装置１００は、セグメントデータを所定の時間間隔毎に定期的に生成している。そのため、送信装置１００で生成されるプレイリストには、時間の経過に従って複数のセグメントデータに関する再生区間情報が記載されることになる。
【００３０】
最大遅延時間Ｔ１が全セグメントデータの時間長以下と判定した場合（Ｓ３０４のＹＥＳ）、再生区間制御部２１３は再生開始までの待ち時間を短くしつつ再生が途切れないようにする最適なセグメントデータを取得するために、Ｓ３０５以降の処理を行う。
【００３１】
まず、再生区間制御部２１３は、セグメントデータ数ｎを１で初期化し（Ｓ３０５）、Ｓ３０１で計測した最大遅延時間Ｔ１が、Ｓ３０３で受信したプレイリストに記載の最新のセグメントデータｎ個の時間長Ｔ３以下か否かを判断する（Ｓ３０６）。セグメントデータは、生成順にプレイリストに記載されるため、プレイリストの最後に記載されたセグメントデータが最も新しいセグメントデータである。
【００３２】
Ｓ３０６で最大遅延時間Ｔ１が最新のセグメントデータｎ個の時間長Ｔ３よりも大きいと判定した場合（Ｓ３０６のＮＯ）、セグメントデータ数ｎを１つ増やし（Ｓ３０７）、再度Ｓ３０６の判断を行う。Ｓ３０６〜Ｓ３０７を繰り返すことにより、最終的にはセグメントデータの時間長の和が最大遅延時間Ｔ１以上となるセグメントデータ数ｎを算出することができる（Ｓ３０６のＹＥＳ）。
【００３３】
続いて、再生区間制御部２１３は、最新のセグメントデータｎ個のうち、未受信の最も古いセグメントデータの取得要求を送信装置１００へ送信する（Ｓ３０８）。なお、Ｓ３０８でのセグメントデータの取得要求も、Ｓ３０２のプレイリスト要求と同様にＨＴＴＰ ＧＥＴメソッドを使用し、Ｓ３０３で受信したプレイリストに記載されたセグメントデータのＵＲＩ情報を参照してリクエストを送信する。
【００３４】
通信部２１２は、Ｓ３０８の要求に従い送信装置１００から送信されたセグメントデータを受信し（Ｓ３０９）、デコーダ部２０９及び表示部２０８においてセグメントデータを復号・再生する（Ｓ３１０）。前述したように、セグメントデータは所定の単位時間に分割されたメディアデータである。
【００３５】
再生区間制御部２１３は、Ｓ３０８で取得要求を送信したセグメントデータがプレイリスト中の最新の（再生順序が最後の）セグメントデータか否かを判断する（Ｓ３１１）。
Ｓ３１１において、セグメントデータが最新のセグメントデータでないと判断された場合には（Ｓ３１１のＮＯ）、未受信のセグメントデータを受信するべくＳ３０８へと処理を戻す。
【００３６】
Ｓ３０５〜Ｓ３１１の処理により、再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が、前述した最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を行うことができる。これにより、本発明の実施形態に係る受信装置１０２は、再生開始までの待ち時間を短くしつつ再生が途切れないようにする最適なセグメントデータを再生することが可能になる。
【００３７】
Ｓ３１１において、セグメントデータが最新のセグメントデータであると判定された場合（Ｓ３１１のＹＥＳ）、再生区間制御部２１３はストリーミングを終了するか否かを判断する（Ｓ３１２）。ここでの判断は、ユーザのストリーミング終了指示を操作部２０４が受信したかを判断することにより可能である。
【００３８】
Ｓ３１２でストリーミングを終了しないと判断した場合には、Ｓ３０２へと処理を戻し、後続のメディアデータ受信処理を継続する。なお、処理を継続する場合には、セグメントデータの時間長から送信装置１００における次のプレイリスト生成タイミングを推測してプレイリスト要求を送信することにより、無駄なプレイリスト要求や応答を削減することが可能である。
【００３９】
Ｓ３０４へと説明を戻し、最大遅延時間Ｔ１が全セグメントデータの時間長よりも大きいと判断された場合には（Ｓ３０４のＮＯ）、再生区間制御部２１３はプレイリストに記載の全てのセグメントデータの取得要求を送信する（Ｓ３１３）。
続いて、通信部２１２は、Ｓ３１３の要求に従い送信装置１００から送信されたセグメントデータを受信する（Ｓ３１４）。また、ＲＡＭ２０２はＳ３１４で受信したセグメントデータをバッファリングする（Ｓ３１５）。
【００４０】
最後に、再生区間制御部２１３は、最大遅延時間Ｔ１から全セグメントデータの時間長Ｔ２を引いた時間を新たにＴ１として設定し（Ｓ３１６）、Ｓ３０２へと処理を戻す。
Ｓ３１３〜Ｓ３１６の処理により、最大遅延時間Ｔ１に満たないセグメントデータをバッファリングし、後続のセグメントデータを受信してバッファが満たされるまで復号・再生を行わないため、再生の途切れを防止することが可能になる。
【００４１】
次に、本実施形態の送信装置１００と受信装置１０２の送受信データの関係について、図６を用いて説明する。図６は、本発明の実施形態に係る送信装置１００と受信装置１０２の送受信データの関係を時間経過と共に示す図である。
【００４２】
６０１、６０２は各々、送信装置１００においてセグメントデータ５及びセグメントデータ６が生成されることを示している。本実施形態では、セグメントデータの生成タイミングは所定の間隔（１秒）で一定であるものとする。なお、６０１以前及び６０２以降にもセグメントデータは生成されているが、図６ではこれらのセグメントデータの生成タイミングは図示しない。セグメントデータ生成の開始と停止は、ユーザが任意に制御することが可能である。
【００４３】
６０３で示すように、受信装置１０２はストリーミング受信開始時に、ネットワーク１０１の通信回線の種類がＷｉ−Ｆｉであることを検出する。したがって、図４に示した通信回線の種類と最大遅延時間とを対応付けたテーブルから、受信装置１０２がストリーミングに要する最大の遅延時間は３秒であると決定することができる。
【００４４】
続いて、受信装置１０２は、プレイリストとセグメントデータとをネットワーク１０１を介して連続して受信することによりメディアデータのストリーミングを行う。
６０４は、受信装置１０２が最初に送受信するプレイリストの要求と応答である。６１０は、６０４のプレイリスト応答により受信したプレイリストであり、セグメントデータ１からセグメントデータ５に関する再生区間情報が記載されている。
【００４５】
プレイリスト６１０中、”ＥＸＴＩＮＦ：１，”は全てのセグメントデータの再生時間長が１秒であることを示しており、”ｈｔｔｐ：／／”で始まる行が各セグメントデータのＵＲＩを示している。
【００４６】
受信装置１０２は、プレイリスト６１０の内容と計測した最大の遅延時間（３秒）とに従って、最新のセグメントデータ５から３秒分のセグメントデータ（＝セグメントデータ３〜セグメントデータ５）を送信装置１００へ順次要求する。そして、受信・再生する（６０５〜６０７）。最大遅延時間の３秒を超えるセグメントデータ１とセグメントデータ２の送受信や復号、再生を行わないため、通信帯域の節約や処理負荷軽減、再生映像のリアルタイム性確保が可能になる。
【００４７】
受信装置１０２は、セグメントデータ３〜セグメントデータ５の受信を終えると、ストリーミングを継続するために再度プレイリストの要求と応答を送受信する（６０８）。６１１は、６０８のプレイリスト応答により受信したプレイリストであり、送信装置１００で新たに生成されたセグメントデータ６（６０２）に関する再生区間情報（１１行目、１２行目）が追記されている。
【００４８】
受信装置１０２は、プレイリスト６１１に記載されたセグメントデータのうち未受信のセグメントデータ６を送信装置１００へ要求、受信し（６０９）、セグメントデータ５に続いて再生することで、途切れること無くスムーズな再生が可能となる。
以上のように、本実施形態の通信装置の再生区間制御処理の結果、ネットワークの種類や通信状況に応じた最大遅延時間に従って最適なメディアデータを受信する。これにより、受信装置１０２の再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することが可能になる。
【００４９】
前述の実施形態では、映像の符号化・復号化方式としてＭＰＥＧ−２を用いたが、ＭＰＥＧ−２に限らずＭＰＥＧ−４  ＡＶＣ／Ｈ．２６４やＶＣ−１など他の映像符号化・復号化方式を用いることが可能である。また、前述の実施形態では、符号化された映像のコンテナ形式としてＭＰＥＧ−２ＴＳを用いたが、ＭＰＥＧ−２ＴＳに限らずＭＰ４形式やＭＯＶ形式などストリーミングに適した他のコンテナ形式を用いることも可能である。
【００５０】
また、前述の実施形態では、プレイリストのフォーマットとしてＭ３Ｕ８形式を用いたが、Ｍ３Ｕ８形式に限らずＭ３Ｕ形式やＷＰＬ形式など他のプレイリストフォーマットを用いることも可能である。
【００５１】
また、前述の実施形態では、データ転送プロトコルとしてＨＴＴＰを用いたが、ＨＴＴＰに限らずＨＴＴＰＳやＴＣＰ、ＵＤＰなどＯＳＩ参照モデルの同一レイヤーの他のプロトコルまたは別レイヤーの他のプロトコルを用いる事が可能である。
【００５２】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、前述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００５３】
２１１  通信制御部
２１２  通信部
２１３  再生区間制御部
【図１】
2015041800.tif 000003
【図２】
2015041800.tif 000004
【図３】
2015041800.tif 000005
【図４】
2015041800.tif 000006
【図５】
2015041800.tif 000007
【図６】
2015041800.tif 000008