(57)【要約】【課題】コンテンツを再生するコンテンツ再生装置の再生タイミングや再生バッファの状況に応じて、音質切り替え時にも違和感のないコンテンツの再生を行うことが可能なコンテンツ再生装置、コンテンツ再生プログラム及びコンテンツ再生方法を提供すること。【解決手段】符号化パラメータ及びビットレートの異なるコンテンツに関するメタ情報をコンテンツサーバから取得し、ネットワークの通信帯域の通信状況を測定し、メタ情報及び通信状況に基づいて、コンテンツサーバから取得するコンテンツのビットレートを決定し、コンテンツサーバに要求し、コンテンツサーバから受信中のコンテンツの符号化パラメータと要求したコンテンツの符号化パラメータの差分の大きさ、及びストリーミング再生するためのバッファの残量に基づいて、受信中のパラメータから要求したパラメータへの段階的切り替え回数を決定し、ビットレートを切り替える。【選択図】図４
2014225810.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続したコンテンツサーバからコンテンツを取得してストリーミング再生するコンテンツ再生装置であって、
符号化パラメータ及びビットレートの異なる前記コンテンツに関するメタ情報を前記コンテンツサーバから取得するメタ情報取得手段と、
前記ネットワークの通信帯域の通信状況を測定する帯域測定手段と、
前記メタ情報及び前記通信状況に基づいて、前記コンテンツサーバから取得する前記コンテンツのビットレートを決定し、前記コンテンツサーバに要求するリクエスト送信手段と、
前記コンテンツサーバから受信中のコンテンツの符号化パラメータと前記要求したコンテンツの符号化パラメータの差分の大きさ、及びストリーミング再生するためのバッファの残量に基づいて、前記受信中の符号化パラメータから前記要求した符号化パラメータへの段階的切り替え回数を決定し、前記ビットレートを切り替えるトランスコード手段と、
を備えることを特徴とするコンテンツ再生装置。
【請求項２】
前記切り替え回数は、前記バッファの「バッファ済サイズ（時間）」−「バッファ最低保持時間」−「トランスコード切替遅延時間」×「切り替え回数」＞「トランスコード初期遅延時間」を満たす切り替え回数であることを特徴とする請求項１に記載のコンテンツ再生装置。
【請求項３】
前記ビットレートの切り替えは、高音質から低音質への切り替えであることを特徴とする請求項１又は２に記載のコンテンツ再生装置。
【請求項４】
前記ビットレートの切り替えは、低音質から高音質への切り替えであることを特徴とする請求項１又は２に記載のコンテンツ再生装置。
【請求項５】
ネットワークに接続したコンテンツサーバからコンテンツを取得してストリーミング再生するコンテンツ再生プログラムであって、
コンピュータに、
符号化パラメータ及びビットレートの異なる前記コンテンツに関するメタ情報を前記コンテンツサーバから取得させ、
前記ネットワークの通信帯域の通信状況を測定させ、
前記メタ情報及び前記通信状況に基づいて、前記コンテンツサーバから取得する前記コンテンツのビットレートを決定させ、前記コンテンツサーバに要求させ、
前記コンテンツサーバから受信中のコンテンツの符号化パラメータと前記要求したコンテンツの符号化パラメータの差分の大きさ、及びストリーミング再生するためのバッファの残量に基づいて、前記受信中の符号化パラメータから前記要求した符号化パラメータへの段階的切り替え回数を決定させ、前記ビットレートを切り替えさせる、
ことを特徴とするコンテンツ再生プログラム。
【請求項６】
ネットワークに接続したコンテンツサーバからコンテンツを取得してストリーミング再生するコンテンツ再生方法であって、
符号化パラメータ及びビットレートの異なる前記コンテンツに関するメタ情報を前記コンテンツサーバから取得し、
前記ネットワークの通信帯域の通信状況を測定し、
前記メタ情報及び前記通信状況に基づいて、前記コンテンツサーバから取得する前記コンテンツのビットレートを決定し、前記コンテンツサーバに要求し、
前記コンテンツサーバから受信中のコンテンツの符号化パラメータと前記要求したコンテンツの符号化パラメータの差分の大きさ、及びストリーミング再生するためのバッファの残量に基づいて、前記受信中の符号化パラメータから前記要求した符号化パラメータへの段階的切り替え回数を決定し、前記ビットレートを切り替える、
ことを特徴とするコンテンツ再生方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信ネットワークを介してコンテンツサーバと接続したコンテンツ再生装置、コンテンツ再生装置で実行されるコンテンツ再生プログラム及びコンテンツ再生方法に関し、特に、コンテンツサーバ内に格納された音声データや映像データ等のコンテンツを、ストリーミング再生することが可能なコンテンツ再生装置、コンテンツ再生プログラム及びコンテンツ再生方法に関する。
【背景技術】
【０００２】
従来、無線通信ネットワークを介してコンテンツサーバと接続したコンテンツ再生装置との間で、動的に変化する通信帯域に応じて、コンテンツ再生装置から動的に音声ストリーム等を選択し再生する技術が開示されている。
【０００３】
例えば、コンテンツ再生装置が、コンテンツサーバに対して、無線通信ネットワークを介してＨＴＴＰ（Hypertext Transfer Protocol：ハイパーテキスト転送プロトコル）でコンテンツの要求を送信する。コンテンツサーバは、この要求に対する応答として要求されたコンテンツを、無線通信ネットワークを介してコンテンツ再生装置に送信する。そして、コンテンツ再生装置が、受信したコンテンツをストリーミング再生するという、所謂コンテンツストリーミングサービスシステムがある。
【０００４】
このようなシステムの１つとして、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）があげられる。ＤＡＳＨでは、ＭＰＤ（Media Presentation Description）データと呼ばれる記述情報（メタデータ）をストリーミング制御に用いる。ＭＰＤデータには、コンテンツの属性、コンテンツを構成するリソースの再生順序などが記述されている。コンテンツ再生装置は、ストリーミングサービスの事前に、あるいはサービス途中に、ＭＰＤデータを受信し、当該ＭＰＤデータを参照して、コンテンツサーバに要求するリソースを決定する。このＭＰＤデータは、対象コンテンツの再生期間を複数の再生期間に分割し、分割された再生期間における情報をピリオドとして記述する。また、ピリオド毎に再生されるリソースの情報を示すリプリゼンテーションを記述する。１つのピリオドには複数のリプリゼンテーションを記述することができる。つまり、コンテンツ再生装置は、１つの再生期間において、複数のリプリゼンテーションから選択した１つのリプリゼンテーションを再生対象とする。
【０００５】
これにより、例えばビットレートの異なる複数のリプリゼンテーションをＭＰＤデータに記述しておくことにより、コンテンツ再生装置はそのときの通信状態や再生能力に応じたビットレートのリプリゼンテーションを選択し、そのリプリゼンテーションで特定されるリソースを取得して再生することができる。
【０００６】
現在、国際標準化により規格化が進んでいるＭＰＥＧ−ＤＡＳＨにおいても、無線通信ネットワーク帯域に応じて、ある時刻単位ごとに映像及び音声データを符号化しておき、コンテンツサーバとコンテンツ再生装置間で動的に変換する帯域に応じて、コンテンツ再生装置から動的にストリームを選択することにより、コンテンツ再生装置で適切な再生を実現している。
【０００７】
図１は、ＭＰＥＧ−ＤＡＳＨによるコンテンツストリーミングサービスシステムの構成例を示す図であり、図２は、ＭＰＥＧ−ＤＡＳＨによるコンテンツの再生例を示す図であり、図３は、通信帯域の異なるコンテンツの再生における問題点を示す図である。
【０００８】
図１、図２及び図３を用いて、ＭＰＥＧ−ＤＡＳＨの概要を説明する。
図１において、コンテンツサーバ１は、例えば、９６キロヘルツ[kHz]（広帯域）、４４．１キロヘルツ[kHz]（中帯域）、８キロヘルツ[kHz]（低帯域）等の複数の通信帯域の無線通信ネットワークを介して、オーディオシステム等のコンテンツ再生装置２Ａ、映像再生システム等のコンテンツ再生装置２Ｂ、又は音楽再生端末等のコンテンツ再生装置２Ｃに対して、音声データや映像データ等のコンテンツを提供する。コンテンツは、例えば、通信帯域に合わせた最適な品質のデータが、１０秒毎のセグメント単位でコンテンツサーバ１からコンテンツ再生装置２Ａ、２Ｂ、２Ｃに送信される。
【０００９】
図２の（Ａ）では、最初の１０秒間（００：００〜００：１０）、２番目の１０秒間（００：１０〜００：２０）、３番目の１０秒間（００：２０〜００：３０）、４番目の１０秒間（００：３０〜００：４０）のコンテンツデータを、９６キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信し再生している。
【００１０】
これに対して、図２の（Ｂ）では、最初、３番目及び４番目の１０秒間のコンテンツデータは、４４．１キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信し再生しているが、２番目の１０秒間のコンテンツデータは、９６キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信し再生している。また、図２の（Ｃ）では、最初、２番目及び４番目の１０秒間のコンテンツデータは、８キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信し再生しているが、３番目の１０秒間のコンテンツデータは、４４．１キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信し再生している。
【００１１】
また、ネットワーク負荷等のシステム環境にリアルタイムに対応してコンテンツ配信を行うため、予め複数の画像品質のコンテンツを作成し、システム環境を監視し最適なコンテンツを送信する技術が開示されている（例えば、特許文献１参照。）。
【００１２】
また、音声帯域変更の影響を実質的に聞こえなくするため、２つの帯域に対応した復号化モードを有し、両帯域間を段階的に変更する技術が開示されている（例えば、特許文献２参照。）。
【００１３】
また、受信装置側で途切れなく放送用の映像及び音声再生を行うため、様々な品質の放送データを受信し、受信データを変換する技術が開示されている。この変換は、受信側の受信バッファの占有率を把握し、バッファのオーバーフロー又はアンダーフローで映像及び音声の破綻が起きないようにトランスコード処理する（例えば、特許文献３参照。）。
【００１４】
図３に示すように、例えば、４４．１キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信して再生したコンテンツから、８キロヘルツ[kHz] の通信帯域の無線通信ネットワークを介して受信して再生したコンテンツへの切り替わりの時点で、再生しているコンテンツの音質に大きな変化がある。また、８キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信して再生したコンテンツから、４４．１キロヘルツ[kHz]の通信帯域の無線通信ネットワークを介して受信して再生したコンテンツへの切り替わりの時点で、再生しているコンテンツの音質に大きな変化がある。そして、このような切り替えを繰り返すと、再生しているコンテンツを聴く際の違和感が大きくなる。
【００１５】
上述したように、ストリームを選択又は切り替えを行う際に、その前後で音声の音質やチャンネル数が大きく異なる場合、コンテンツ再生装置での再生音声の聞こえ方が急激に変わり、違和感のある再生がなされることがある。このような違和感のある生成を防ぐために、切り替え部分のコンテンツをトランスコード処理している。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】国際公開第ＷＯ２００４/４０９０８号
【特許文献２】特表２００３−５３３７１７号公報
【特許文献３】特開２００３−２５９３３３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
しかしながら、従来の技術では、コンテンツを再生するコンテンツ再生装置の再生タイミングや再生バッファの状況に関わらず、一律に所定のトランスコード処理を実行しており、必ずしも違和感のない再生が行われるとは限らない。
【００１８】
１つの側面では、本発明は、音質切り替え時にも違和感のないコンテンツの再生を行うことが可能なコンテンツ再生装置、コンテンツ再生プログラム及びコンテンツ再生方法を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明は、上記課題を解決するため、下記のような構成を採用した。
１つの案では、ネットワークに接続したコンテンツサーバからコンテンツを取得してストリーミング再生するコンテンツ再生装置であって、符号化パラメータ及びビットレートの異なる前記コンテンツに関するメタ情報を前記コンテンツサーバから取得するメタ情報取得手段と、前記ネットワークの通信帯域の通信状況を測定する帯域測定手段と、前記メタ情報及び前記通信状況に基づいて、前記コンテンツサーバから取得する前記コンテンツのビットレートを決定し、前記コンテンツサーバに要求するリクエスト送信手段と、前記コンテンツサーバから受信中のコンテンツの符号化パラメータと前記要求したコンテンツの符号化パラメータの差分の大きさ、及びストリーミング再生するためのバッファの残量に基づいて、前記受信中の符号化パラメータから前記要求した符号化パラメータへの段階的切り替え回数を決定し、前記ビットレートを切り替えるトランスコード手段とを備えることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、音質切り替え時にも違和感のないコンテンツの再生を行うことできる、という効果を奏する。
【図面の簡単な説明】
【００２１】
【図１】ＭＰＥＧ−ＤＡＳＨによるコンテンツストリーミングサービスシステムの構成例を示す図である。
【図２】ＭＰＥＧ−ＤＡＳＨによるコンテンツの再生例を示す図である。
【図３】通信帯域の異なるコンテンツの再生における問題点を示す図である。
【図４】本実施の形態のシステム構成図である。
【図５】メタ情報１２の構成例を示す図である。
【図６】本実施の形態の特徴を説明する図である。
【図７】データ受信部２４の処理の流れを示すフローチャートである。
【図８】トランスコード指示部２６の処理の流れを示すフローチャートである。
【図９】サブルーチン「トランスコードシーケンス作成」処理の流れを示すフローチャートである。
【図１０】トランスコード部２７の処理の流れを示すフローチャートである。
【図１１】実施例１を示す図である。
【図１２】実施例２を示す図である。
【図１３】実施例３を示す図である。
【図１４】実施例４を示す図である。
【図１５】実施例５を示す図である。
【図１６】実施例６を示す図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
図４は、本実施の形態のシステム構成図であり、図５は、メタ情報の構成例を示す図である。
【００２３】
図４において、コンテンツサーバ１０は、無線通信ネットワークを介してコンテンツ再生装置２０と接続している。
【００２４】
コンテンツサーバ１０は、多様なネットワーク通信帯域に対応するために、符号化パラメータ及びビットレートの異なる複数のコンテンツ、例えば音声データを作成する。以下、コンテンツの一例として音声データを用い、本発明の実施の形態について説明する。ここで、符号化パラメータは、例えばサンプリング周波数、量子化ビット数、チャンネル数などである。作成した音声データは、コンテンツサーバ１０がアクセス可能なコンテンツデータベース（ＤＢ）１１に格納する。コンテンツサーバ１０は、コンテンツＤＢ１１に格納されたコンテンツに関するメタ情報１２を有する。コンテンツサーバ１０は、リクエスト受信部１３及びデータ配信部１４を備える。
【００２５】
リクエスト受信部１３は、コンテンツサーバ１０からの音声データの送信要求を受信し、要求された音声データをコンテンツＤＢ１１から取得し、送信要求してきたコンテンツ再生装置２０を特定する識別子とともにデータ配信部１４に渡す。
【００２６】
データ配信部１４は、リクエスト受信部１３が取得した音声データを、例えば１０秒毎のセグメント単位で、識別子で特定されたコンテンツ再生装置２０に無線通信ネットワークを介して配信する。
【００２７】
コンテンツ再生装置２０は、メタ情報取得部２１、帯域測定部２２、リクエスト送信部２３、データ受信部２４、セグメント通知部２５、トランスコード指示部２６、トランスコード部２７、及びコンテンツ再生部２８を備え、後述するコンテンツ再生処理を実行する。すなわち、コンテンツ再生装置２０が備える不図示のＣＰＵ（Central Processing Unit：中央処理装置）が、コンテンツ再生プログラムを実行することにより、コンテンツＤＢ１１に格納された音声データをコンテンツサーバ１０から取得し、ストリーミング再生する。
【００２８】
メタ情報取得部２１は、図５に例示したような音声データに関するメタ情報１２をコンテンツサーバ１０から取得する。図５に示したメタ情報１２は、メタデータ、区間情報、グループ情報、及びセグメント情報が階層構造で構成されている。メタデータは、時間ごとに分割された情報を持つ。区間情報は、映像データ、音声データなどの複数のグループの情報を持つ。グループ情報は、それぞれ複数の品質のセグメントに関する情報を持つ。そして、セグメント情報は、メディアの最小単位であるセグメントのバイト位置や時刻情報などを持つ。
【００２９】
帯域測定部２２は、コンテンツサーバ１０とコンテンツ再生装置２０間の通信帯域の監視を行い、最適な通信状態の通信帯域とメタ情報１２に基づいて、次にどのビットレートの音声データを要求し受信するかを決定する。
【００３０】
リクエスト送信部２３は、帯域測定部２２が決定した通信帯域の音声データの送信をコンテンツサーバ１０に要求する。
【００３１】
また、帯域測定部２２は、コンテンツサーバ１０のメタ情報１２を参照し、トランスコード指示部２６に対して、コンテンツサーバ１０に要求した音声データに関する符号化パラメータを含む帯域変化通知を送信する。
【００３２】
データ受信部２４は、コンテンツサーバ１０のデータ配信部１４から配信された音声データをセグメント単位で受信する。
【００３３】
セグメント通知部２５は、データ受信部２４が音声データを受信したことをトランスコード指示部２６に通知する。
【００３４】
トランスコード指示部２６は、帯域測定部２２より新たに通知された符号化パラメータ（新パラメータ）と、前回通知された符号化パラメータ（現パラメータ）を比較する。トランスコード指示部２６は、これらの両符号化パラメータが異なり、例えば新セグメントのサンプリング周波数の方が低音質の場合、メタ情報１２とデータ受信部２４で受信中の現在のセグメントのデータ受信状況から、パラメータ切り替わりまでの時間を推定し、該時間内で段階的にパラメータを新パラメータに近づけるよう、トランスコード部２７にパラメータと共にトランスコード開始指示を出す。また、トランスコード指示部２６は、両パラメータが異なり、新セグメントの方が高音質の場合、データ受信部２４からの新セグメント受信通知を待ち、新セグメント受信通知を受信後に適切な時間内で段階的にパラメータを新パラメータに近づけるよう、トランスコード部２７にパラメータと共にトランスコード指示を出す。更に、トランスコード指示部２６は、トランスコードのタイミング、パラメータ、及び切り替え回数の決定を、以下の（ａ）乃至（ｇ）の手順に従って行う。なお、ここでいう切り替え回数は、トランスコードの設定値が変わる回数であり、トランスコードをしていない状態からトランスコードをする状態への変化は切り替え回数には入れないものとする。
【００３５】
（ａ）コンテンツ再生部２８の「バッファ済みサイズ（時間）」を取得する。
【００３６】
（ｂ）トランスコードを行うことによる遅延によってバッファ保持部２９のバッファが枯渇し音声が途切れることがないようにするため、下記の（式１）を満たす場合にのみ    
（ｃ）以降の処理を行い、トランスコードを行う。
「バッファ済みサイズ（時間）」−「バッファ最低保持時間」＞「トランスコード初期遅延」  ・・・（式１）
【００３７】
ここで、「バッファ最低保持時間」は、音声データの視聴を安定させるために、コンテンツ再生部２８に最低限確保しておくバッファ量である。また、「トランスコード初期遅延」は、トランスコード部２７からフードバックを受けて値を更新していくものとする。
【００３８】
（ｃ）トランスコードのパラメータを切り替える際に生じる遅延によってバッファ保持部２９のバッファが枯渇し音声が途切れることがないようにするために、トランスコード切り替え可能回数を下記の（式２）を満たす整数Ｘの最大値を求めることにより算出する。
「バッファ済みサイズ（時間）」−「バッファ最低保持時間」−Ｘ×「トランスコード切り替え遅延」＞「トランスコード初期遅延」  ・・・（式２）
【００３９】
ここで、「トランスコード切り替え遅延」は、トランスコード部２７からフードバックを受けて値を更新していくものとする。
【００４０】
（ｄ）バッファを不用意に消費しないため、（ｃ）で求めたＸが、規定値であるトランスコード切り替え可能回数の最大値（トランスコード切り替え基準回数）を超える場合は、Ｘにトランスコード切り替え基準回数を代入する。
【００４１】
（ｅ）上記で求めたＸ＋１通りのトランスコードの符号化パラメータを決定する。
ｉ番目の符号化パラメータ（「符号化パラメータ［ｉ］」）は、例えばパラメータを等間隔で設定する場合は下記の（式３）で求める。
「符号化パラメータ［ｉ］」＝「現セグメントパラメータ」−（ｉ＋１）×（「現セグメントパラメータ」−「新セグメントパラメータ」）／（Ｘ＋２）    （ｉ：０〜Ｘ）  ・・・（式３）
【００４２】
（ｆ）セグメント切り替わりまでの時間を、メタ情報１２に記載されているセグメント長（時間）と、現在のパケットの受信状況から推定する。
【００４３】
（ｇ）Ｘ＋１個のトランスコード開始及び切り替えのタイミングを決定する。
ｉ番目のトランスコード開始及び切り替えタイミングは、例えば等間隔の場合は下記の（式４）で求める。
「トランスコード開始／切り替えタイミング［ｉ］」＝Ｔｓ＋ｉ×（Ｔｅ−Ｔｓ）／（Ｘ＋１）    （ｉ：０〜Ｘ），Ｔｓ：トランスコード開始時刻，Ｔｅ：トランスコード終了時刻    ・・・（式４）
【００４４】
ここで、「トランスコード開始時刻」Ｔｓは、新セグメントの方が低音質の場合は現時刻であり、新セグメントの方が高音質の場合は新セグメント開始時刻である。また、「トランスコード終了時刻」Ｔｅは、新セグメントの方が低音質の場合は現セグメント終了時刻であり、新セグメントの方が高音質の場合は新セグメント開始から一定時間（トランスコード切り替え基準時間）後である。
【００４５】
そして、新セグメントの方が低音質の場合、トランスコード指示部２６は、セグメント通知部２５から新セグメントの受信通知を受けると、トランスコード部２７にシーケンス番号を含めたトランスコード停止指示を送信する。また、新セグメントの方が高音質の場合、トランスコード指示部２６は、トランスコード開始指示からトランスコード切り替え基準時間を経過すると、トランスコード部２７にトランスコード停止指示を送信する。
【００４６】
トランスコード部２７は、トランスコード指示部２６からトランスコード指示を受け取ると、受け取ったパラメータに基づいてトランスコードを行い、コンテンツ再生部２８に引き渡す。
【００４７】
コンテンツ再生部２８は、トランスコード部２７を通過した音声データを再生することで、音質を段階的に変化させる。
【００４８】
これにより、コンテンツ再生装置２０では、ネットワークの帯域の変化により、たとえば、広帯域なレートから低帯域なレートに配信ストリームを切り替えた際に、視聴の安定性を崩すことなく、瞬間的な音質の変化を抑止することができ、違和感を生じさせない再生が実現できる。
【００４９】
図６は、本実施の形態の特徴を説明する図である。
上述したように、本実施の形態のコンテンツ再生装置２０は、音質の異なる音声データの連結箇所をトランスコードし、音質を段階的に変化させたシーケンスを挿入する。トランスコードのタイミング、パラメータ、切り替え回数の決定には、切り替えまでの時間、切り替え前の音質、切り替え後の音質、バッファ済みサイズ、トランスコードにかかる時間、トランスコード切り替え基準時間、及びトランスコード切り替え基準回数を用いる。バッファ済みサイズが大きければ、図６（Ａ）に示したように、トランスコードの切り替え回数は多くなり、バッファ済みサイズが小さければ、図６（Ｂ）に示したように、トランスコードの切り替え回数は少なくなる。
【００５０】
図７は、データ受信部２４の処理の流れを示すフローチャートである。
まず、ステップＳ７０１において、リクエスト受信部１３から音声データをセグメント単位で受信する。
【００５１】
ステップＳ７０２において、ステップＳ７０１で受信した音声データのセグメントが新セグメントであるか否かを判断する。
【００５２】
新セグメントでないと判断された場合（ステップＳ７０２：Ｎｏ）は、ステップＳ７０４へ進み、他方、あると判断された場合（ステップＳ７０２：Ｙｅｓ）は、ステップＳ７０３において、トランスコード指示部２６へ新セグメントの受信を通知する。
【００５３】
そして、ステップＳ７０４において、トランスコード部２７へ音声データをデータ転送する。
【００５４】
図８は、トランスコード指示部２６の処理の流れを示すフローチャートであり、図９は、サブルーチン「トランスコードシーケンス作成」処理の流れを示すフローチャートである。
【００５５】
まず、ステップＳ８０１において、帯域測定部２２で測定したコンテンツサーバ１０とコンテンツ再生装置２０間の通信帯域の帯域変化通知を受信したか否かを判断する。
【００５６】
受信すると（ステップＳ８０１：Ｙｅｓ）、ステップＳ８０２において、現音声データの音質が新音声データの音質より良いか否かを判断する。
【００５７】
良いと判断された場合（ステップＳ８０２：Ｙｅｓ）、ステップＳ８０３において、サブルーチン「トランスコードシーケンス作成」処理を実行する。
【００５８】
サブルーチン「トランスコードシーケンス作成」処理は、まず、図９のステップＳ９０１において、コンテンツ再生部２８のバッファ済みサイズ（時間）を取得する。
【００５９】
ステップＳ９０２において、バッファ保持部２９のバッファが十分であるか否かを判断する。具体的には、「バッファ済みサイズ（時間）」−「バッファ最低保持時間」＞「トランスコード初期遅延」を満たすか否かを判断する。
【００６０】
バッファが十分でなければ（ステップＳ９０２：Ｎｏ）、ステップＳ９０３において、トランスコードせずに終了する。
【００６１】
他方、バッファ保持部２９のバッファが十分であれば（ステップＳ９０２：Ｙｅｓ）、ステップＳ９０４において、トランスコード切り替え可能回数（Ｘ）を計算する。具体的には、「バッファ済みサイズ（時間）」−「バッファ最低保持時間」−Ｘ×「トランスコード切り替え遅延」＞「トランスコード初期遅延」を満たす最大の整数Ｘを求める。
【００６２】
ステップＳ９０５において、ステップＳ９０４で求めたＸが規定値であるトランスコード切り替え可能回数の最大値（トランスコード切り替え基準回数）を超えるか否かを判断する。
【００６３】
超える場合（ステップＳ９０５：Ｙｅｓ）は、ステップＳ９０６において、Ｘにトランスコード切り替え基準回数を代入する。
【００６４】
他方、超えない場合（ステップＳ９０５：Ｎｏ）は、直ちにステップＳ９０７において、Ｘ＋１個の符号化パラメータを決定する。具体的には、ｉ番目の符号化パラメータ（「符号化パラメータ［ｉ］」）として、「現セグメントパラメータ」−（ｉ＋１）×（「現セグメントパラメータ」−「新セグメントパラメータ」）／（Ｘ＋２）の算出結果を用いる。
【００６５】
ステップＳ９０８において、現音声データから新音声データへの切り替えにかける時間を算出する。現音声データの音質が新音声データの音質より高音質である場合は、メタ情報１２にあるセグメント長（時間）と、現在のパケット受信状況から算出する。逆に、新音声データの音質が現音声データの音質より高音質である場合は、トランスコード切り替え基準時間を用いる。
【００６６】
ステップＳ９０９において、Ｘ＋１個のトランスコード開始及び切り替えのタイミングを決定する。具体的には、ｉ番目のトランスコード開始及び切り替えタイミングとして、「トランスコード開始時刻」＋ｉ×（「トランスコード終了時刻」−「トランスコード開始時刻」）／（Ｘ＋１）の算出結果を用いる。
【００６７】
そして、図８のステップＳ８０３のサブルーチン「トランスコードシーケンス作成」処理を終了する。
【００６８】
ステップＳ８０４において、トランスコード部２７に対してシーケンスに沿ったトランスコード指示を送信する。
【００６９】
ステップＳ８０５において、新セグメントの受信が通知（図７のステップＳ７０３）されたか否かを判断する。
【００７０】
通知されない場合（ステップＳ８０５：Ｎｏ）は、ステップＳ８０４に戻り、他方、通知された場合（ステップＳ８０５：Ｙｅｓ）は、ステップＳ８０６において、トランスコード部２７にトランスコード停止指示を送信してステップＳ８０１へ戻る。
【００７１】
ステップＳ８０２で現音声データの音質が新音声データの音質より良くないと判断された場合（ステップＳ８０２：Ｎｏ）、ステップＳ８０７において、サブルーチン「トランスコードシーケンス作成」処理を実行する。
【００７２】
ステップＳ８０８において、新セグメントの受信が通知されたか否かを判断する。
新セグメントの受信が通知されたら（ステップＳ８０８：Ｙｅｓ）、ステップＳ８０９において、タイマーにより所定時間、例えばトランスコード切り替え基準時間までのカウント開始を設定し、ステップＳ８１０において、トランスコード部２７に対してシーケンスに沿ったトランスコード指示を送信する。
【００７３】
ステップＳ８１１において、ステップＳ８０９で設定したタイマーの終了時間を経過したか否かを判断する。
【００７４】
終了時間を経過していなければ（ステップＳ８１１：Ｎｏ）、ステップＳ８１０に戻り、他方、経過していれば（ステップＳ８１１：Ｙｅｓ）、ステップＳ８１２において、トランスコード部２７にトランスコード停止指示を送信してステップＳ８０１へ戻る。
【００７５】
図１０は、トランスコード部２７の処理の流れを示すフローチャートである。
まず、ステップＳ１００１において、データ受信部２４から音声データを受信する。
【００７６】
ステップＳ１００２において、新たなトランスコード指示を受信したか否かを判断する。
【００７７】
新たなトランスコード指示でなければ（ステップＳ１００２：Ｎｏ）、ステップＳ１００５へ進み、他方、新たなトランスコード指示であれば（ステップＳ１００２：Ｙｅｓ）、ステップＳ１００３において、トランスコード中に設定し、ステップＳ１００４において、トランスコードパラメータを設定する。
【００７８】
ステップＳ１００５において、トランスコード停止指示を受信したか否かを判断する。
トランスコード停止指示を受信した場合（ステップＳ１００５：Ｙｅｓ）、ステップＳ１００６において、トランスコード停止中に設定してステップＳ１００７へ進む。他方、トランスコード停止指示を受信していない場合（ステップＳ１００５：Ｎｏ）、直ちにステップＳ１００７において、トランスコード中に設定されているか否かを判断する。
【００７９】
トランスコード中に設定されていれば（ステップＳ１００７：Ｙｅｓ）、ステップＳ１００８において、受け取ったパラメータに基づいてトランスコードを実行して、ステップＳ１００９へ進む。他方、トランスコード中でなければ（ステップＳ１００７：Ｎｏ）、ステップＳ１００９において、コンテンツ再生部２８に音声データを引き渡す。
【００８０】
次に、本実施の形態におけるより具体的な実施例１乃至６を説明する。
図１１は、実施例１を示す図である。
【００８１】
実施例１は、サンプリング周波数が９６キロヘルツ[kHz]の音声データから４４．１キロヘルツ[kHz]の音声データへの切り替えであり、音声データの１０秒のセグメントのうち、データ受信部２４が６．２秒付近を受信している状態における時点での処理である。
【００８２】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。新音声データの音質が４４．１キロヘルツ[kHz]とすると、現音声データの音質９６キロヘルツ[kHz]の方が高音質である。
【００８３】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（５秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は１秒ある。
【００８４】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（１秒）を下回るように切り替え回数を計算する。すなわち、１＞０．３５＋Ｘ×０．３であるＸは「２」となる。
【００８５】
切り替え回数がトランスコード切り替え基準回数を下回っているため、切り替え回数をそのまま切り替え回数とする。すなわち、Ｘは２となる。
【００８６】
途中の切り替えが２回であるので、３つの符号化パラメータを決定する。等分とすると、８３キロヘルツ[kHz]、７０キロヘルツ[kHz]、及び５７キロヘルツ[kHz]となる。
【００８７】
現音声データの音質の方が新音声データの音質より高音質であるため、メタ情報取得部２１のセグメント情報（１０秒）と、データ受信部２４の現在受信中の時刻（６．２秒）から、切り替わりまでの時間を計算する。すなわち、３．８（＝１０−６．２）秒後に切り替える。
【００８８】
途中の切り替えが２回であるので、３つの切り替えタイミングを決定する。等分すると、０秒後、１．３秒後、及び２．５秒後となる。
【００８９】
トランスコード指示部２６からトランスコード部２７へ、０秒後に８３キロヘルツ[kHz]、１．３秒後に７０キロヘルツ[kHz]、２．５秒後に５７キロヘルツ[kHz]にトランスコードするように指示を送信する。
【００９０】
そして、トランスコード指示部２６が、データ受信部２４から新セグメント受信通知を受信した後、トランスコード部２７に停止指示を送信する。
【００９１】
図１２は、実施例２を示す図である。
実施例２は、実施例１で用いた「サンプリング周波数」の代わりに「量子化ビット数」を用いた例である。すなわち、２４ビット[bit]の音声データから１６ビット[bit]の音声データへの切り替えであり、音声データの１０秒のセグメントのうち、データ受信部２４が６．２秒付近を受信している状態における時点での処理である。
【００９２】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。現音声データの音質２４ビット[bit]の方が新音声データの音質１６ビット[bit]より高音質である。
【００９３】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（５秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は１秒ある。
【００９４】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（１秒）を下回るように切り替え回数を計算する。すなわち、１＞０．３５＋Ｘ×０．３であるＸは「２」となる。
【００９５】
切り替え回数がトランスコード切り替え基準回数を下回っているため、切り替え回数をそのまま切り替え回数とする。すなわち、Ｘは２となる。
【００９６】
途中の切り替えが２回であるので、３つの符号化パラメータを決定する。等分とすると、２２ビット[bit]、２０ビット[bit]、及び１８ビット[bit]となる。
【００９７】
現音声データの音質の方が新音声データの音質より高音質であるため、メタ情報取得部２１のセグメント情報（１０秒）と、データ受信部２４の現在受信中の時刻（６．２秒）から、切り替わりまでの時間を計算する。すなわち、３．８（＝１０−６．２）秒後に切り替える。
【００９８】
途中の切り替えが２回であるので、３つの切り替えタイミングを決定する。等分すると、０秒後、１．３秒後、及び２．５秒後となる。
【００９９】
トランスコード指示部２６からトランスコード部２７へ、０秒後に２２ビット[bit]、１．３秒後に２０ビット[bit]、２．５秒後に１８ビット[bit]にトランスコードするように指示を送信する。
【０１００】
そして、トランスコード指示部２６が、データ受信部２４から新セグメント受信通知を受信した後、トランスコード部２７に停止指示を送信する。
【０１０１】
図１３は、実施例３を示す図である。
実施例３は、実施例１で用いた「サンプリング周波数」の代わりに「チャンネル数」を用いた例である。すなわち、７．１チャネル[ch]の音声データから２チャネル[ch]の音声データへの切り替えであり、音声データの１０秒のセグメントのうち、データ受信部２４が６．２秒付近を受信している状態における時点での処理である。
【０１０２】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。現音声データの音質７．１チャネル[ch]の方が新音声データの音質２チャネル[ch]より高音質である。
【０１０３】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（５秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は１秒ある。
【０１０４】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（１秒）を下回るように切り替え回数を計算する。すなわち、１＞０．３５＋Ｘ×０．３であるＸは「２」となる。
【０１０５】
切り替え回数がトランスコード切り替え基準回数を下回っているため、切り替え回数をそのまま切り替え回数とする。すなわち、Ｘは２となる。
【０１０６】
途中の切り替えが２回であるので、３つの符号化パラメータを決定する。ほぼ等分とすると、６．１チャネル[ch]、４．１チャネル[ch]、及び３．１チャネル[ch]となる。
【０１０７】
現音声データの音質の方が新音声データの音質より高音質であるため、メタ情報取得部２１のセグメント情報（１０秒）と、データ受信部２４の現在受信中の時刻（６．２秒）から、切り替わりまでの時間を計算する。すなわち、３．８（＝１０−６．２）秒後に切り替える。
【０１０８】
途中の切り替えが２回であるので、３つの切り替えタイミングを決定する。等分すると、０秒後、１．３秒後、及び２．５秒後となる。
【０１０９】
トランスコード指示部２６からトランスコード部２７へ、０秒後に６．１チャネル[ch]、１．３秒後に４．１チャネル[ch]、２．５秒後に３．１チャネル[ch]にトランスコードするように指示を送信する。
【０１１０】
そして、トランスコード指示部２６が、データ受信部２４から新セグメント受信通知を受信した後、トランスコード部２７に停止指示を送信する。
【０１１１】
図１４は、実施例４を示す図である。
実施例４は、サンプリング周波数が高音質の９６キロヘルツ[kHz]の音声データから低音質の４４．１キロヘルツ[kHz]の音声データへの切り替えである実施例１に代わり、低音質の４４．１キロヘルツ[kHz]の音声データから高音質の９６キロヘルツ[kHz]の音声データへの切り替えである。そして、１０秒ずつの音声データのセグメントのうち、データ受信部２４が１７秒付近を受信している状態における時点での処理である。
【０１１２】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。現音声データの音質４４．１キロヘルツ[kHz]の方が新音声データの音質９６キロヘルツ[kHz]より低音質である。
【０１１３】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（６秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は２秒ある。
【０１１４】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（２秒）を下回るように切り替え回数を計算する。すなわち、２＞０．３５＋Ｘ×０．３であるＸは「５」となる。
【０１１５】
切り替え回数がトランスコード切り替え基準回数を上回っているため、トランスコード切り替え基準回数を切り替え回数とする。すなわち、Ｘは３となる。
【０１１６】
途中の切り替えが３回であるので、４つの符号化パラメータを決定する。等分とすると、５４キロヘルツ[kHz]、６５キロヘルツ[kHz]、７５キロヘルツ[kHz]、及び８６キロヘルツ[kHz]となる。
【０１１７】
現音声データの音質の方が新音声データの音質より低音質であるため、トランスコード開始からトランスコード終了までの時間をトランスコード切り替え基準時間（３秒）とし、トランスコード開始は新セグメント受信時とする。
【０１１８】
途中の切り替えが３回であるので、４つの切り替えタイミングを決定する。等分すると、新セグメントの受信から０秒後、０．８秒後、１．５秒後、及び２．３秒後となる。
【０１１９】
トランスコード指示部２６は、データ受信部２４から新セグメント受信通知を受信した後、トランスコード切り替え基準時間（３秒）のタイマーをセットする。
【０１２０】
上記新セグメント受信通知を契機に、トランスコード指示部２６からトランスコード部２７へ、０秒後に５４キロヘルツ[kHz]、０．８秒後に６５キロヘルツ[kHz]、１．５秒後に７５キロヘルツ[kHz]、２．３秒後に８６キロヘルツ[kHz]にトランスコードするように指示を送信する。
【０１２１】
そして、トランスコード指示部２６は、タイマーが切れたらトランスコード部２７に停止指示を送信する。
【０１２２】
図１５は、実施例５を示す図である。
実施例５は、実施例４で用いた「サンプリング周波数」の代わりに「量子化ビット数」を用いた例である。すなわち、１６ビット[bit]の音声データから２４ビット[bit]の音声データへの切り替えであり、１０秒ずつの音声データのセグメントのうち、データ受信部２４が１７秒付近を受信している状態における時点での処理である。
【０１２３】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。現音声データの音質１６ビット[bit]の方が新音声データの音質２４ビット[bit]より低音質である。
【０１２４】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（６秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は２秒ある。
【０１２５】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（２秒）を下回るように切り替え回数を計算する。すなわち、２＞０．３５＋Ｘ×０．３であるＸは「５」となる。
【０１２６】
切り替え回数がトランスコード切り替え基準回数を上回っているため、トランスコード切り替え基準回数を切り替え回数とする。すなわち、Ｘは３となる。
【０１２７】
途中の切り替えが３回であるので、４つの符号化パラメータを決定する。等分とすると、１８ビット[bit]、１９ビット[bit]、２１ビット[bit]、及び２２ビット[bit]となる。
【０１２８】
現音声データの音質の方が新音声データの音質より低音質であるため、トランスコード開始からトランスコード終了までの時間をトランスコード切り替え基準時間（３秒）とし、トランスコード開始は新セグメント受信時とする。
【０１２９】
途中の切り替えが３回であるので、４つの切り替えタイミングを決定する。等分すると、新セグメントの受信から０秒後、０．８秒後、１．５秒後、及び２．３秒後となる。
【０１３０】
トランスコード指示部２６は、データ受信部２４から新セグメント受信通知を受信した後、トランスコード切り替え基準時間（３秒）のタイマーをセットする。
【０１３１】
上記新セグメント受信通知を契機に、トランスコード指示部２６からトランスコード部２７へ、０秒後に１８ビット[bit]、０．８秒後に１９ビット[bit]、１．５秒後に２１ビット[bit]、２．３秒後に２２ビット[bit]にトランスコードするように指示を送信する。
【０１３２】
そして、トランスコード指示部２６は、タイマーが切れたらトランスコード部２７に停止指示を送信する。
【０１３３】
図１６は、実施例６を示す図である。
実施例６は、実施例４で用いた「サンプリング周波数」の代わりに「チャネル数」を用いた例である。すなわち、２チャネル[ch]の音声データから７．１チャネル[ch]の音声データへの切り替えであり、１０秒ずつの音声データのセグメントのうち、データ受信部２４が１７秒付近を受信している状態における時点での処理である。
【０１３４】
トランスコード指示部２６が、帯域測定部２２からの帯域変化通知を受信する。現音声データの音質２チャネル[ch]の方が新音声データの音質７．１チャネル[ch]より低音質である。
【０１３５】
コンテンツ再生部２８のバッファ保持部２９のバッファ量（６秒）が、バッファ最低保持時間（４秒）よりも多いため、バッファは十分と判断する。余裕は２秒ある。
【０１３６】
トランスコード初期遅延とトランスコード切り替え遅延の合計が、上記の余裕（２秒）を下回るように切り替え回数を計算する。すなわち、２＞０．３５＋Ｘ×０．３であるＸは「５」となる。
【０１３７】
切り替え回数がトランスコード切り替え基準回数を上回っているため、トランスコード切り替え基準回数を切り替え回数とする。すなわち、Ｘは３となる。
【０１３８】
途中の切り替えが３回であるので、４つの符号化パラメータを決定する。等分とすると、３チャネル[ch]、４チャネル[ch]、５．１チャネル[ch]、及び６．１チャネル[ch]となる。
【０１３９】
現音声データの音質の方が新音声データの音質より低音質であるため、トランスコード開始からトランスコード終了までの時間をトランスコード切り替え基準時間（３秒）とし、トランスコード開始は新セグメント受信時とする。
【０１４０】
途中の切り替えが３回であるので、４つの切り替えタイミングを決定する。等分すると、新セグメントの受信から０秒後、０．８秒後、１．５秒後、及び２．３秒後となる。
【０１４１】
トランスコード指示部２６は、データ受信部２４から新セグメント受信通知を受信した後、トランスコード切り替え基準時間（３秒）のタイマーをセットする。
【０１４２】
上記新セグメント受信通知を契機に、トランスコード指示部２６からトランスコード部２７へ、０秒後に３チャネル[ch]、０．８秒後に４チャネル[ch]、１．５秒後に５．１チャネル[ch]、２．３秒後に６．１チャネル[ch]にトランスコードするように指示を送信する。
【０１４３】
そして、トランスコード指示部２６は、タイマーが切れたらトランスコード部２７に停止指示を送信する。
【０１４４】
以上、本発明の実施の形態を説明してきたが、上述のコンテンツ再生装置２０は、通常の情報処理装置（コンピュータ）を使用して実現することができる。すなわち、コンテンツ再生装置２０は、ＣＰＵ、ＲＡＭやＲＯＭ等のメモリ、入力装置、出力装置、外部記録装置、媒体駆動装置、及びネットワーク接続装置を備える。また、これらはバスにより互いに接続されている。
【０１４５】
メモリは、コンテンツ再生装置２０に用いられるプログラム及びデータを格納する。ＣＰＵは、メモリを利用してプログラムを実行することにより、上述のコンテンツ再生処理を実行する。
【０１４６】
入力装置は、例えば、キーボード、ポインティングデバイス等であり、ユーザからの指示や情報の入力に用いられる。出力装置は、例えば、表示装置、プリンタ、スピーカ等であり、ユーザへの問い合わせや処理結果の出力に用いられる。
【０１４７】
外部記録装置は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。この外部記録装置には、ハードディスクドライブも含まれる。コンテンツ再生装置２０は、この外部記録装置にプログラム及びデータを格納しておき、それらをメモリにロードして使用することができる。
【０１４８】
媒体駆動装置は、可搬型記録媒体を駆動し、その記録内容にアクセスする。可搬型記録媒体は、メモリデバイス、フレキシブルディスク、光ディスク、光磁気ディスク等である。この可搬型記録媒体には、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＵＳＢ（Universal Serial Bus）メモリ等も含まれる。ユーザは、この可搬型記録媒体にプログラム及びデータを格納しておき、それらをメモリにロードして使用することができる。
【０１４９】
このように、コンテンツ再生処理に用いられるプログラム及びデータを格納するコンピュータ読み取り可能な記録媒体には、メモリ、外部記録装置、及び可搬型記録媒体のような、物理的な（非一時的な）記録媒体が含まれる。
【０１５０】
ネットワーク接続装置は、ＬＡＮ（Local Area Network）等の有線または無線の通信ネットワークに接続され、通信に伴うデータ変換を行う通信インタフェースである。コンテンツ再生装置２０は、プログラム及びデータを外部の装置からネットワーク接続装置を介して受け取り、それらをメモリにロードして使用することができる。
【０１５１】
例えば、外部記録装置に格納したプログラムやデータは、コンテンツ再生装置２０のメモリにロードされる。また、ネットワーク接続装置を介して接続可能な外部装置は、プログラムやデータを搬送する搬送信号を生成し、通信ネットワーク上の任意の伝送媒体を介してコンテンツ再生装置２０に送信する。
【０１５２】
開示した実施の形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができる。
【符号の説明】
【０１５３】
１        コンテンツサーバ
２Ａ、２Ｂ、２Ｃ  コンテンツ再生装置
１０      コンテンツサーバ
１１      コンテンツデータベース（ＤＢ）
１２      メタ情報
１３      リクエスト受信部
１４      データ配信部
２０      コンテンツ再生装置
２１      メタ情報取得部
２２      帯域測定部
２３      リクエスト送信部
２４      データ受信部
２５      セグメント通知部
２６      トランスコード指示部
２７      トランスコード部
２８      コンテンツ再生部
２９      バッファ保持部
【図２】
2014225810.tif 000003
【図３】
2014225810.tif 000004
【図５】
2014225810.tif 000005
【図６】
2014225810.tif 000006
【図７】
2014225810.tif 000007
【図８】
2014225810.tif 000008
【図９】
2014225810.tif 000009
【図１０】
2014225810.tif 000010
【図１１】
2014225810.tif 000011
【図１２】
2014225810.tif 000012
【図１３】
2014225810.tif 000013
【図１４】
2014225810.tif 000014
【図１５】
2014225810.tif 000015
【図１６】
2014225810.tif 000016
【図１】
2014225810.tif 000017
【図４】
2014225810.tif 000018