JP6021385B2 - ストリーミングメディア再生装置、ストリーミングメディア再生方法、及びプログラム - Google Patents

Description

本発明は、映像ストリーミング配信等のストリーミングメディア配信技術に関連するものである。

従来のインターネット向けの映像配信方式の１つとして、メディアファイルを予め複数に分割しておき、それらをHTTPで配信する方式がある（例：Http Live Streaming (HLS)）。また、上記の方式を拡張した配信方式として、映像コンテンツをインデックス化し、XML型メタ情報を定義した映像配信方式も提案されている（例：Dynamic Adaptive Streaming over Http (DASH)）。

特開２００２−２６２２６２号公報

HLS等のインデックスを持たない従来の映像配信技術では、ジャンプ、早送り、巻き戻し等のトリックプレイを可能とするために、映像ファイルの全解析を行ったり、トリックプレイ用の別の映像ファイルを作成する必要があるなど、実装に大きな負担がかかるという課題があった。

本発明は上記の点に鑑みてなされたものであり、従来のように実装に大きな負担をかけることなく、ストリーミングメディアにおけるトリックプレイを実現するための技術を提供することを主な目的とする。

上記の課題を解決するために、本発明は、ネットワーク接続されたストリーミングメディア配信装置からメディアコンテンツをダウンロードして再生するストリーミングメディア再生装置であって、
前記メディアコンテンツにおける特定の時間位置へのジャンプ指示を受けたときに、当該メディアコンテンツに対応するインデックス情報を参照することにより、前記時間位置に対応する所定単位のデータを特定し、当該特定したデータと、それ以降のデータを前記ストリーミングメディア配信装置に順次要求して取得するメディアデータ取得処理手段と、
前記メディアデータ取得処理手段により取得されたメディアデータを再生する再生手段とを備えたことを特徴とするストリーミングメディア再生装置として構成される。

前記所定単位のデータは、例えばGOPのデータである。

また、本発明は、ネットワーク接続されたストリーミングメディア配信装置からメディアコンテンツをダウンロードして再生するストリーミングメディア再生装置であって、
前記メディアコンテンツにおける特定の時間位置の時点で、早送り又は巻き戻しの指示を受けたときに、当該メディアコンテンツに対応するインデックス情報を参照することにより、前記時間位置に対応する所定種別のフレームデータを特定し、当該特定したフレームデータと、それ以降又はそれ以前の前記所定種別のフレームデータを前記ストリーミングメディア配信装置に順次要求して取得するメディアデータ取得処理手段と、
前記メディアデータ取得処理手段により取得されたフレームデータを再生する再生手段とを備えたことを特徴とするストリーミングメディア再生装置として構成することもできる。

早送り又は巻き戻しを行う場合において、前記再生手段は、予め定めた条件に従って、メディアコンテンツを通常再生する場合のビットレートよりも低いビットレートで再生を行うようにしてもよい。

早送り又は巻き戻しを行う場合において、前記メディアデータ取得処理手段は、メディアコンテンツを通常再生する場合のタイムスタンプを所定の条件に従って変更したタイムスタンプを前記再生手段に通知するようにしてもよい。

また、本発明は、ストリーミングメディア再生装置が実行するストリーミングメディア再生方法、コンピュータを、ストリーミングメディア再生装置の各手段として機能させるためのプログラムとして構成することもできる。

本発明によれば、従来のように実装に大きな負担をかけることなく、ストリーミングメディアにおけるトリックプレイを実現するための技術を提供することが可能となる。

本発明の実施の形態で用いるメディア配信方式を説明するための図である。 本発明の実施の形態で用いるメディア配信方式を説明するための図である。 本発明の実施の形態に係るシステム構成図である。 ダウンロード速度測定の動作を説明するための図である。 トリックプレイにおけるGOPの特定処理を説明するための図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態ではメディア配信方式としてDASHを用いることを想定しているが、本発明を適用可能なメディア配信方式はDASHに限られるわけではない。また、配信されるメディアは、MPEGでエンコードしたストリーミング映像コンテンツであることを想定しているが、本発明はこれに限られない。

（本実施の形態のメディア配信方式について）
まず、本実施の形態で用いられるメディア配信方式について説明する。なお、以下で説明するメディア配信方式の内容は、本発明に関係する部分を主に説明するものである。

このメディア配信方式においては、図１に示すように、メディアコンテンツが複数のセグメントに分けられる。各セグメントは、複数のGOP（Group of Pictures）を含む。ここでのGOPは、Iフレームから、次のIフレームの前までの一連のメディアデータである。

また、このメディア配信方式においては、メディアコンテンツに対応するインデックス情報が用意されている。このインデックス情報は、各セグメントのメディアコンテンツにおける時間位置と、メディアコンテンツにおけるデータ位置を含む。ここでの「時間位置」とは、本実施の形態では、メディアコンテンツの開始を起点とした該当セグメントのメディアが始まる時間（時刻）と、当該セグメントの時間長とからなるものである。これは開始時間及び終了時間からなるものでもよい。また、本実施の形態における「データ位置」は、メディアコンテンツの開始を起点とした当該セグメントの先頭のバイト位置と、当該セグメントのバイト長（サイズ）からなる。また、開始バイト位置及び終了バイト位置からなるものでもよい。

また、本実施の形態では、セグメント毎に、図２に示すように、セグメント内の各GOPに対応するインデックス情報が用意されているとともに、各GOP内のIフレーム、Pフレーム、最初のBフレームに対応するインデックス情報を有する。図２の例では、例えば、セグメント２の中のGOP２に対して、インデックスS２が用意されている。このインデックスS２は、例えば、セグメント２の中のGOP２の相対的な開始時間と時間長、及び開始データ位置とサイズを有する。

また、例えば、GOP２の中のIフレームに対応するインデックスL１は、例えば、当該IフレームのGOP２の中の相対的な開始時刻と時間長、及び開始データ位置とサイズを含む。GOP２の中の最初のPフレームに対応するインデックスL２は、例えば、当該PフレームのGOP２の中の相対的な開始時刻と時間長、及び開始データ位置とサイズを含む。

本メディア配信方式において、各セグメントには、セグメント情報として、当該セグメントのネットワーク上の位置情報（ネットワーク位置情報）が付与されており、ユーザ端末は、このネットワーク位置情報を指定してセグメントを取得することができる。本実施の形態では、このネットワーク位置情報はHTTP URLであり、ユーザ端末は、このURLを指定したHTTP GETリクエストにより、セグメントを取得する。ただし、メディアコンテンツのデータを取得するための信号は、HTTP GETリクエストに限られるわけではなく、他の信号を用いて取得してもよい。

また、インデックス情報を用いることで、１つのセグメント内のデータ位置やデータ範囲を指定することにより、特定のGOPのデータを取得することも可能である。また、特定のGOPの中の特定のフレームのデータを取得することも可能である。なお、ネットワーク位置情報及びインデックス情報はメタ情報と呼ぶことができる。

更に、本メディア配信方式では、メディアのビットレート（帯域とも呼び、映像でいえば画質、画像の縦横の画素数等に対応）毎に、別々のメディアコンテンツ及びメタ情報が用意されており、ユーザ端末は、所望のビットレートのメディアコンテンツのネットワーク位置情報を指定することで、所望のビットレートのメディアコンテンツのセグメントを取得できる。

上記のネットワーク位置情報及びインデックス情報は、メディアコンテンツに対応付けられたメタ情報として、メディア配信装置側に格納されており、ユーザ端末は、必要に応じてネットワーク位置情報及び必要に応じてインデックス情報をメディア配信装置から取得し、取得した情報を用いて、メディアコンテンツのダウンロード、及び再生を行う。

（システム構成）
図３に、本発明の実施の形態に係るシステム構成を示す。図３に示すように、本実施の形態のシステムは、メディア配信装置１とユーザ端末２とがネットワーク３（例えばインターネット）を介して接続された構成を有する。ユーザ端末２は、ストリーミングメディア再生装置と称してもよい。

メディア配信装置１は、メタ情報格納部１１、メディアコンテンツ格納部１２、情報配信制御部１３を備える。

メタ情報格納部１１は、前述したメタ情報を格納する。メディアコンテンツ格納部１２は、メディアコンテンツを格納する。情報配信制御部１３は、ユーザ端末２からの要求に基づいて、メタ情報やメディアデータをユーザ端末２に送信する機能部である。

ユーザ端末２は、ユーザインタフェース部２１、メタ情報取得部２２、メタ情報格納部２３、メディアデータ取得処理部２４、ダウンロード速度監視部２５、ビットレート変更判定部２６、メディア再生処理部２７を備える。また、図示していないが、現在のビットレートや、処理に必要な各種パラメータ等を格納する記憶手段を備える。

ユーザインタフェース部２１は、ユーザによるユーザ端末２に対する操作指示を受け付け、その指示内容を各機能部に通知する機能部である。ユーザインタフェース部２１はディスプレイ（表示部）と一体化した機能部であってもよいし、ディスプレイはユーザ端末２に接続される別の装置であってもよい。

本実施の形態における指示としては、再生開始、トリックプレイ等がある。また、ユーザインタフェース部２１は、メディア配信装置１もしくはその他のWebサーバ等から、メディアコンテンツ選択用のページ情報を受信して表示し、どのメディアを視聴するかをユーザに選択させ、選択されたメディアに関するメタ情報（メディアの全長時間等の基本的な情報を含む）を取得して、メタ情報格納部２３に格納する機能を備えてもよい。また、上記の機能を、ユーザ端末２に含まれるWebブラウザが実行し、メタ情報を取得することで、アプリケーションを起動し、当該アプリケーションが起動することにより、図３に示すユーザ端末２の各機能部が構成される形態を採用してもよい。

メタ情報取得部２２は、処理に必要なメタ情報をメディア配信装置１から取得し、メタ情報格納部２３に格納する機能部である。例えば、トリックプレイの指示を受けたときに、必要なインデックス情報がユーザ端末２になかった場合に、当該メディアに対応するインデックス情報を取得する。メタ情報格納部２３は、メタ情報を格納し、メタ情報を用いて処理を行う各機能部から適宜参照される。

メディアデータ取得処理部２４は、バッファ２４１（メモリ）を有し、メタ情報格納部２３に格納されているメタ情報を用いて、必要なメディアデータをメディア配信装置１から取得し、バッファ２４１に格納する。バッファ２４１に格納されたメディアデータは、メディア再生処理部２７にタイムスタンプとともに渡される。メディア再生処理部２７はメディア再生処理を行う。

例えば、メディアの通常の再生の場合、メディアデータ取得処理部２４は、セグメントのネットワーク位置情報を用いて、順次セグメントを取得し、バッファ２４１に格納するとともに、メディア再生処理部２７は、バッファ２４１に格納されたメディアデータを順次取得して再生処理を行い、ディスプレイに表示する。

ダウンロード速度監視部２５は、メディアデータ取得処理部２４が取得するメディアデータのダウンロード速度を測定する。また、ビットレート変更判定部２６は、ダウンロード速度等に応じて、ビットレートの変更を行うか否かを判定し、変更が必要な場合は、ビットレートの変更を行って、変更後のビットレートをメディアデータ取得処理部２４及びメディア再生処理部２７に通知する。ダウンロード速度の測定及びビットレート変更判定については後に詳細に説明する。

また、メディアデータ取得処理部２４は、トリックプレイ制御機能を含み、ユーザインタフェース部２１からトリックプレイの指示を受けた場合に、トリックプレイを実行するための制御を行う。トリックプレイについても詳細は後述する。

なお、本実施の形態では、ダウンロード速度の測定・ビットレート変更判定の機能と、トリックプレイの機能の両方を備えることとしているが、これらのうちのどちらか一方のみを備えることとしてもよい。

ユーザ端末２は、コンピュータ本体とディスプレイが分離した一般的なPCでもよいし、スマートフォン等のように、操作部と表示部が一体化したタッチパネルを備える端末でもよい。また、これら以外の端末であってもよい。

ユーザ端末２、メディア配信装置１のいずれも、通信機能を有するコンピュータに、本実施の形態で説明する処理に対応するプログラムを実行させることにより実現可能である。当該プログラムは、可搬メモリ等の記憶媒体に格納して配布し、上記コンピュータにインストールして用いてもよいし、ネットワーク上のサーバからダウンロードして上記コンピュータにインストールしてもよい。

（ダウンロード速度測定）
次に、上述したユーザ端末２が実行するダウンロード速度の測定について説明する。

本実施の形態におけるダウンロード速度監視部２５は、セグメントデータの取得開始(HTTP GETリクエスト発行)を基点として、GOP受信毎にダウンロード速度を測定する。

より具体的には、GOP受信時点から過去一定時間に受信したデータ量および受信に要した時間（すなわち、当該一定時間）からダウンロード速度を算出する。ただし、HTTP GETリクエストを起点とし、当該HTTP GETリクエストを跨ってのダウンロード速度計測は行わない。上記の「一定時間」とは、予め定めておく時間である。また、HTTP GETリクエスト発行から最初のセグメントデータ到着までの遅延時間を考慮し、この遅延時間についてはダウンロード速度計測の対象外としている。

図４に、ダウンロード速度測定の動作イメージを示す。この動作の前提として、ユーザ端末２のメタ情報格納部２３には、該当メディアに関する各セグメントのインデックス情報と各GOPについてのインデックス情報が格納されており、HTTP GETリクエストに係るセグメントについてのインデックス情報を参照できるものとする。つまり、HTTP GETリクエストに係るセグメントの最初からどのバイト位置にどのGOPの先頭（末尾）があるかを把握できる。

ユーザ端末２のメディアデータ取得処理部２４からHTTP GETリクエストが送信されると、メディア配信装置１は、当該リクエストで要求されたセグメントデータをユーザ端末２に向けて送信することを開始する。

ユーザ端末２のメディアデータ取得処理部２４は、メディアデータを連続的に受信し、バッファ２４１に格納し、バッファ２４１からメディアデータがメディア再生処理部２７に渡される。

一方、ダウンロード速度監視部２５は、所定の短い時間毎に受信データ量（つまり、バッファに入れられたデータ量）を計測している。また、ダウンロード速度監視部２５は、インデックス情報を参照することにより、最初にデータ受信したときからの受信データ量に基づいて、１個１個のGOPを受信したことを認識する。すなわち、例えば、ダウンロード速度監視部２５は、インデックス情報に基づいて、GOP１のデータ量がYバイトであることを把握し、最初からYバイト目を受信したときに、GOP１のデータを受信完了したことを判断できる。次に、ダウンロード速度監視部２５は、インデックス情報に基づいて、GOP２のデータ量がXバイトであることを把握し、GOP１のデータ受信の後、Xバイト目を受信したときに、GOP２を受信したことを把握できる。このようにして、セグメントに含まれるGOP毎に、受信ポイント（受信時間）を判断できる。以下では、この受信ポイントを測定ポイントとも呼ぶ。

ダウンロード速度監視部２５は、GOPの測定ポイント毎に、過去の一定時間前から現在（受信ポイントの時点）までに受信したデータ量を、この一定時間で割ることにより、ダウンロード速度を算出する。

なお、図４では、「一定時間」が、GOPの２つ分程度となっているが、これは図示の便宜上の一例に過ぎない。また、「一定時間」前の時点が、最初のデータを受信する前の時間を含む場合(図４の例では、GOP１とGOP２の測定ポイントの場合）、つまり、最初にデータを受信してから測定ポイントまでの時間が、「一定時間」より短い場合には、「一定時間」に代えて、最初にデータを受信してから、測定ポイントまでの時間を用いることとしてよい。

上記のように、GOPを受信する毎に、一定時間の間に受信したデータ量に基づくダウンロード速度を算出することにより、GOP毎のダウンロード速度の変動を均すことができ、測定結果として急激なダウンロード速度の変動が生じることを回避して、適切なダウンロード速度を得ることができる。ただし、この場合の「一定時間」は、１つのGOPを受信するためにかかる時間より長い時間である。

上記の測定方法のように、GOPを受信する度に「一定時間」の間に受信したデータ量に基づきダウンロード速度を測定することに代えて、GOPを受信する度に、当該GOPの１つ前のGOP受信完了から当該GOP受信完了までに受信したデータ量をその間の時間で割ることでダウンロード速度を算出してもよい。この方法は、例えば、GOP毎の速度変動が少ないと予想されるネットワーク環境において適している。

上記のようにして測定されたダウンロード速度は、例えば、ユーザ端末２の表示部に表示してもよい。本実施の形態では、以下のようにして、ダウンロード速度に基づいて、ビットレート変更判定を行っている。

（ビットレート変更判定）
ダウンロード速度監視部２５は、ダウンロード速度を測定する度に、測定したダウンロード速度をビットレート変更判定部２６に通知する。

＜ビットレートを下げるための判定処理＞
ビットレート変更判定部２６は、ダウンロード速度監視部２５から通知された現在のダウンロード速度で、次のGOPをダウンロードした場合に、GOPのダウンロードが完了するまでに、バッファ２４１が枯渇してしまうかどうかをダウンロード速度測定の度に判定し、枯渇してしまう場合にメディアのビットレートを下げると判断する。なお、ここでは、一例として、次のGOPをダウンロードした場合に、GOPのダウンロードが完了するまでに、バッファ２４１が枯渇してしまうかどうかを判定することとしているが、次の１つのGOPではなく、以降の複数個のGOPをダウンロードした場合についての判定を行うこととしてもよい。

また、バッファ２４１が枯渇してしまうかどうかを判定することも一例に過ぎない。「枯渇」は、メディアコンテンツの再生に支障をきたす状態の例であり、メディアコンテンツの再生に支障をきたすその他の状態を判定に用いてもよい。例えば、バッファ２４１の蓄積量が予め定めた量以下になったかどうか、もしくは、バッファ２４１の蓄積量がメディアデータ全体に対する所定％以下になったかどうかを判定して、ビットレートの変更を判定してもよい。

例えば、図４の例において、GOP３を受信した時点で算出したダウンロード速度がX kbit/sであったとし、次に受信するGOP４のサイズをインデックス情報から３Ｘ kbitであることを把握したとする。この場合、３Ｘ kbitのデータを受信するのに３Ｘ÷Ｘ＝３秒かかると算出される。また、ビットレート変更判定部２６は、GOP３を受信した時点でのバッファ２４１のデータ蓄積量が１０Ｘkbitであることを把握したとする。そして、このときのメディアのビットレートが５Xkbit/sであるとすると、ほぼ５Xkbit/sの速さでバッファ２４１からデータが取得され、その分のバッファのデータが減少していく。そうすると、ＧＯＰ４を受信するのにかかる３秒では、１５Xkbitのデータがバッファから取得されるはずである。しかし、GOP３を受信した時点でのバッファ２４１のデータ蓄積量が１０Ｘkbitであり、GOP４のサイズが３Ｘkbitであるから、これらを合計すると１３kbitとなり、１５Xkbitより少ない。よって、３秒の間に、バッファ２４１のデータが枯渇する（０になる）ことになる。バッファ２４１のデータが枯渇すると、メディア再生において、映像が止まったりして、再生品質が低下する。

そこで、本実施の形態のビットレート変更判定部２６は、この場合にビットレートを下げると判断する。

本実施の形態では、ビットレート変更判定部２６は、ビットレートを下げると判断した場合に、直前に算出したダウンロード速度（現時点でのＧＯＰ受信で算出したダウンロード速度）の定倍（これをＤ倍とする）を上回らない最大のビットレートを変更後のビットレートとして選択する。

例えば、Ｄ倍が３倍、現在のダウンロード速度がX kbit/s、現在のビットレートが５X kbit/s、これより下のビットレートとして、２．５X kbit/sと、X kbit/sがある場合において、ダウンロード速度を下げる場合、X kbit/sのＤ倍（３倍）を上回らない最大のビットレートである２．５Xkbit/sを変更後のビットレートとして選択する。なお、このＤ倍は、適切な値を予め定めておく。例えば、本方式でのダウンロード速度、ビットレート、バッファ量などの間の関係を実験等により測定し、Ｄ倍として適切な値を予め定めておいてもよいし、理論値等を用いてもよい。もしくは、これらの関係を一定時間毎にビットレート変更判定部２６が把握し、動的にＤ倍を決定してもよい。

例えば、上記の例で、Ｄ倍を２倍と定めていた場合、X kbit/sが選択されることになるが、このとき、仮にバッファ２４１に多くのデータが保持されることが継続する状況が発生する場合、より高速のビットレートを使用してもよかったことになる。高速なビットレートのほうが、ユーザは高品質の映像を視聴できるので好ましい。上記の状況をできるだけ少なくし、可能な限りユーザに快適なメディア再生環境を提供するために、Ｄ倍を上回らない最大のビットレートを変更後のビットレートとして選択するに際してのＤ倍が定められる。

ビットレート変更判定部２６は、上記のようにして変更した変更後のビットレートをメディアデータ取得処理部２４、メディア再生処理部２７に通知する。変更後のビットレートに対応するメディアコンテンツのメタ情報がメタ情報格納部２３にあれば、メディアデータ取得処理部２４は、次に取得すべきメディアデータに対応するネットワーク位置情報（変更後のビットレートに対応するメディアデータのネットワーク位置情報）をメタ情報及びインデックス情報から作成してリクエストをメディア配信装置１に送信することで該当のメディアデータを取得し、これを繰り返してビットレート変更後のメディアデータ取得を行うとともに、メディア再生処理部２７は、変更後のビットレートでメディア再生を行う。

変更後のビットレートに対応するメディアコンテンツのメタ情報がメタ情報格納部２３にない場合は、メディアデータ取得処理部２４の指示により、メタ情報取得部２２がメタ情報を取得し、メタ情報格納部２３に格納した後に、上記の処理が行われる。

＜ビットレートを上げるための判定処理＞
また、ビットレート変更判定部２６は、現在のビットレートの１つ上のビットレートの定倍（これをＵ倍とする）以上のダウンロード速度を一定時間以上維持できたかどうかを、当該一定時間毎に判定している。もしくは、この「一定時間」よりも長い時間間隔で、「一定時間」以上維持できたかどうかの判定を行うようにしてもよい。

現在のビットレートの１つ上のビットレートのＵ倍以上のダウンロード速度を一定時間以上維持できた場合には、一つ上のビットレートを選択し、ビットレート変更を行う。ビットレートを変更した後の処理は、ビットレートを下げる場合と同じである。なお、ここでは一例として、一つ上のビットレートを選択することとしているが、一つ上のビットレート以外のビットレート（例えば、２つ上、３つ上など）を選択することとしてもよい。

例えば、測定結果のダウンロード速度が２．５Xkbit/s〜３Ｘkbit/sの範囲で一定時間以上継続し、現在のメディアのビットレートが０．５Xkbit/sであり、これより上のビットレートとして、Xkbit/sと２．５Xkbit/sがあり、Ｕ倍が２倍である場合を想定する。この場合、１つ上のビットレートであるXkbit/sの２倍は２Xkbit/sであり、上記想定例では、２Xkbit/s以上を一定時間以上維持できたから、ビットレートをXkbit/sにすると判定する。

上記の例で、例えば、ビットレートを上げた後に、すぐにビットレートを下げる状況が発生した場合、すぐにビットレートが下げられることになる。しかし、ビットレートの変更が頻繁に起こることは、ユーザにとって好ましくない。よって、この場合は、Ｕ倍として、例えば、３倍が設定されていればよかったことになる。３倍であれば、ビットレートを上げる判断は行われないからである。ただし、倍率を上げすぎると、ビットレートを上げても支障がないのに、ビットレートを上げないという場合が発生し易くなるため好ましくない。

なお、このU倍は、適切な値を予め定めておく。例えば、本方式でのダウンロード速度、ビットレート、バッファ量などの間の関係を実験等により測定し、U倍として適切な値を予め定めておいてもよいし、理論値等を用いてもよい。もしくは、これらの関係を一定時間毎にビットレート変更判定部２６が把握し、動的にU倍を決定してもよい。

また、Ｄ倍、Ｕ倍の両者において、動的に定倍を定める場合に、ダウンロード速度の長期時間における移動平均を常時算出し、その変動が大きい場合は定倍を大きく設定し、小さい場合には定倍を小さくするようにしてもよい。また、 ビットレート変更後のダウンロード速度から定倍を見直すこととしてもよい。

なお、上記の例における各定倍、ビットレート、バッファ量、ダウンロード速度の例は、説明を分かり易くするための便宜上のものであり、上記の各定倍の具体例が実際の適切な値であるとは限らない。

＜ビットレート変更のその他の例＞
ビットレートの決定においては、ダウンロード速度を用いずに、バッファ時間が一定の時間を下回ればビットレートを一つ下に下げるという方法を採用してもよい。バッファ時間とは、データがバッファに格納されてから読み出されるまでの時間であり、ビットレート変更判定部２６が測定する。

また、ビットレート変更判定部２６は、ダウンロード速度を用いずに、バッファ量の変更を見るだけでビットレートを変更するようにしてもよい。

また、ビットレート変更判定部２６は、ダウンロード速度を用いずに、TCPレイヤでのパケット送受信（SYN→SYN,ACK）におけるRTTを算出し、RTTが所定値よりも大きい場合にビットレートを下げ、所定値以下の場合にビットレートを上げる制御を行うこともできる。

更に、ダウンロード速度の長期トレンドと短期トレンドを比較して、その傾向からビットレート変更の判断をするようにしてもよい。例えば、短期トレンドで速度が低下しても、長期トレンドで低下傾向がなければビットレートを維持するといった判断を行うことが可能である。ここでの長期トレンドとは、例えば、ＧＯＰ受信毎に測定されるダウンロード速度についての時間ウィンドウＴでの移動平均値（ＧＯＰ受信毎に算出される）の一定期間内の増減量であり、短期トレンドとは、時間ウィンドウＴより短い時間での時間ウィンドウにおける移動平均値の一定期間内の増減量である。なお、長期トレンドと短期トレンドはこれに限られるわけではなく、種々の解析手法を用いて長期トレンドと短期トレンドを把握可能である。この長期トレンドと短期トレンドの判断は、前述したダウンロード速度を用いたビットレート変更判定の結果において、変更するとの判定が出た場合において、実際の変更を行うか否かを決定するために用いてもよい。
なお、再生開始時の初期ビットレートは初期設定において選択した帯域を上回らない最大の値を選択することとしてもよい。

映像配信においては、ユーザ端末側で適切な映像再生制御を行うために、映像のダウンロード速度の測定がなされることが好ましいが、従来技術においては、例えば、映像データを格納するファイルの単位でしかダウンロード速度を測定することができず、細かな時間単位でのダウンロード速度を算出することができなかった。

そのため、速度低下に対する検知が遅れ、ビットレートの変更の対処を適切に行うことができずに、映像が停止しやすいという課題があったが、上述した本実施の形態に係る技術により、この課題が解決される。

（トリックプレイ）
次に、トリックプレイの処理について説明する。

＜ジャンプ＞
メディアデータ取得処理部２４は、ユーザインタフェース部２１から、ジャンプの指示を受ける。例えば、ユーザがメディアを視聴中に、画面上に表示される操作部において、メディアコンテンツの開始から所定時間の位置T（例えば、メディアの開始から３０分後の時点）を指定し、この位置へのジャンプを指示すると、ユーザインタフェース部２１は、T"３０分"の情報を含むジャンプ指示をメディアデータ取得処理部２４に送る。

メディアデータ取得処理部２４は、メタ情報格納部２３にアクセスして、現在視聴中のメディアコンテンツに対応するインデックス情報を参照する。ここでもし必要とするインデックス情報がない場合は、メディアデータ取得処理部２４はメタ情報取得部２２にインデックス情報を取得させ、取得されたインデックス情報を用いる。

メディアデータ取得処理部２４は、指定された時間位置Tに対応するセグメントおよびセグメント内のバイト位置を特定する。

例えば、セグメントのインデックス情報における時間情報に基づいて、時間位置Tを含むセグメントがセグメント１０であると特定されたものとすると、次に、セグメント１０内のGOP毎のインデックス情報を参照し、時間位置Tに該当するGOPの先頭のバイト位置を特定する。時間位置Tに該当するGOPとは、例えば、時間位置Tに最も近い先頭を持つGOPとすることができる。例えば、図５に示すように、インデックス情報から把握できるセグメント１０の先頭の時間位置がT−TΔであるとすると、セグメント１０においてTΔに最も近い時間位置を先頭に持つGOP４がジャンプ先として特定されることになる。このGOP４のセグメント先頭からのバイト位置はインデックス情報から取得できる。

メディアデータ取得処理部２４は、上記のようにして特定されたセグメントのネットワーク位置情報（HTTP-URL)とその中のバイト位置を指定して、メディア配信装置１に対してメディアデータ取得要求を送信し、メディアデータを取得し、以降は通常の配信と同様にメディア取得配信が行われる。

上記の例では、ジャンプをGOP単位で行うこととしているが、ジャンプをセグメント単位で行うこととしてもよい。また、インデックス情報を用いて、時間位置とバイト位置を把握できる限りにおいて、フレーム単位でのジャンプを行うこととしてもよい。

＜早送り・巻き戻し＞
次に、早送り・巻き戻しの処理について説明する。メディアデータ取得処理部２４は、ユーザインタフェース部２１から、早送りの指示を受けるとする。例えば、ユーザがメディアを視聴中に、画面上に表示される操作部において、早送りボタンを選択すると、その選択情報がユーザインタフェース部２１に通知され、ユーザインタフェース部２１は早送りの指示をメディアデータ取得処理部２４に対して行う。この早送りの指示には、指示の時点でのメディアの開始からの時間の情報が含まれているものとする。

早送りの指示を受けたメディアデータ取得処理部２４は、ジャンプの場合と同様にして、指示の時点のメディア時間位置情報とインデックス情報を用いて、早送りの指示を受けた時点に対応するメディアコンテンツのGOPを特定する。更に、当該GOPのインデックス情報を参照することにより、Iフレームのバイト位置及びサイズを特定した後、対象となるセグメントからIフレームのみを要求するリクエストをメディア配信装置１に送り、Iフレームをダウンロードする。

以後は、設定で定めた早送りの倍速率に応じて、次のIフレームを特定し、コンテンツの終端に達するか、ユーザ操作により再生状態に切り替えられるまで、Iフレームのダウンロード、デコードを繰り返す。例えば、早送りの倍速率に応じて、連続するIフレームを選択したり、所定個数おきにIフレームを選択する。

巻き戻しの場合も早送りの場合と同様にして、指示を受けた時点のIフレームを特定し、メディアの開始方向に、順次Iフレームを特定し、コンテンツの先頭に達するか、ユーザ操作により再生状態に切り替えられるまで、Iフレームのダウンロード、デコードを繰り返す。

なお、本実施の形態において、メディア再生処理部２７の動画再生機能では、早送り・巻き戻しの機能は搭載されていないことを想定しており、そのため、メディア再生処理部２７へ通知するタイムスタンプを操作することにより、メディア再生処理部２７の動画再生機能に対して早送り・巻き戻しを意識させることなく、早送り・巻き戻し機能を実現できるようにしている。タイムスタンプの操作に関しては、メディアデータ取得処理部２４が、実際のタイムスタンプ×1/N（N倍速の場合）のタイムスタンプを疑似的に付けてデータをメディア再生処理部２７に渡す。

従来技術では、トリックプレイ実施時にビットレートの変更はできなかったが、本実施の形態ではビットレートの変更が可能である。すなわち、ジャンプ、早送り・巻き戻しにおいて、これらを実行後にも、継続して、前述したダウンロード速度を用いる方法を使用してビットレート変更判定を行って、ビットレートを見直すことができる。また、早送り・巻き戻しに関しては、早送り・巻き戻し中はビットレートの変更判定を行わず、通常再生に移った後にビットレート見直しを行うこととしてもよい。また、ジャンプする場合、ビットレートの見直しを行って、ジャンプを行ってもよい。この場合、ビットレート決定後に、そのビットレートに対応したメディアのインデックス情報を用いてジャンプ位置の決定を行う。

早送り・巻き戻しにおいて前述したようにダウンロード速度を用いてビットレート変更判定を行う際のダウンロード速度は、Iフレームを受信する度（要求に係るIフレーム相当サイズのデータを受信する度）に、当該Iフレームを受信した時点から過去一定時間の間に受信したデータ量を用いて算出することができる。

また、早送り・巻き戻し中はビットレートを落として表示してもよい。つまり、この場合、早送り・巻き戻しの指示を受けた場合には、異なるビットレートのメディアコンテンツに係るメタ情報を利用するとともに、当該異なるビットレートのメディアコンテンツのIフレームを取得する。

この場合、例えば、高ビットレートで再生中は、中ビットレートで早送り・巻き戻しを行い、中ビットレートで再生中は、低ビットレートで早送り・巻き戻しを行い、また、低ビットレートで再生中は、ビットレートを落とさないこととする。定義された複数ビットレートのうちのどれを高ビットレートとし、どれを中ビットレートとし、どれを低ビットレートとするかは予め定めておき、ユーザ端末２に設定しておく。

＜本実施の形態に係るトリックプレイの効果について＞
従来のRTP方式のIPTVでは、サーバ側でIフレームのみを抜き出した映像を事前あるいは逐次準備することで、早送り・巻き戻し時に順次配信をしている。また、HLSではIフレームのみを抜き出すことができないため、事前にIフレームのみを抜き出した映像を準備しておくか、または、N倍の速度ですべてのダウンロードをしておきIフレームを端末で抜き出すこととなる。

一方、本実施の形態に係る技術では、インデックス情報により、セグメントの中からIフレームのみを抽出するため、最低限のネットワーク転送量で早送り・巻き戻し機能を実現できる。

（実施の形態の効果）
インデックス情報を有するメディア配信方式を用いてメディア再生機能を実装することで、GOP単位のダウンロード速度算出を実現し、ビットレートの切り替えをGOP単位で行うことができるようになる。また、これまで高負荷だったトリックプレイをインデックス情報により低負荷で行うことができるようになる。従って、ユーザの利便性は向上し、ネットワーク利用において効率がよくなる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ メディア配信装置
２ ユーザ端末
３ ネットワーク
１１ メタ情報格納部
１２ メディアコンテンツ格納部
１３ 情報配信制御部
２１ ユーザインタフェース部
２２ メタ情報取得部
２３ メタ情報格納部
２４ メディアデータ取得処理部
２４１ バッファ
２５ ダウンロード速度監視部
２６ ビットレート変更判定部
２７ メディア再生処理部

Claims (3)

1. ネットワーク接続されたストリーミングメディア配信装置からメディアコンテンツをダウンロードして再生するストリーミングメディア再生装置であって、
   前記メディアコンテンツは複数のセグメントを有し、各セグメントは複数のGOPのデータを有し、
   前記メディアコンテンツにおけるセグメント毎の時間位置を示す情報と当該時間位置に対応するデータ位置を示す情報、及び各セグメントにおけるGOP毎の時間位置を示す情報と当該時間位置に対応するデータ位置を示す情報を含むインデックス情報を前記ストリーミングメディア配信装置から取得するメタ情報取得手段と、
   前記インデックス情報を格納するための格納手段と、
   前記メディアコンテンツにおける特定の時間位置へのジャンプ指示を受けたときに、当該メディアコンテンツに対応する前記インデックス情報が前記格納手段にない場合に、前記メタ情報取得手段に前記インデックス情報を取得させ、当該取得されたインデックス情報を参照することにより、前記特定の時間位置を含むセグメントを特定し、当該セグメントにおいて前記特定の時間位置に最も近い先頭を持つGOPのデータ位置を特定し、当該データ位置の特定がなされたGOPのデータと、それ以降のデータを前記ストリーミングメディア配信装置に順次要求して取得するメディアデータ取得処理手段と、
   前記メディアデータ取得処理手段により取得されたメディアデータを再生する再生手段と、
   を備えたことを特徴とするストリーミングメディア再生装置。
2. ネットワーク接続されたストリーミングメディア配信装置からメディアコンテンツをダウンロードして再生するストリーミングメディア再生装置が実行するストリーミングメディア再生方法であって、
   前記メディアコンテンツは複数のセグメントを有し、各セグメントは複数のGOPのデータを有し、
   前記ストリーミングメディア再生装置は、前記メディアコンテンツにおけるセグメント毎の時間位置を示す情報と当該時間位置に対応するデータ位置を示す情報、及び各セグメントにおけるGOP毎の時間位置を示す情報と当該時間位置に対応するデータ位置を示す情報を含むインデックス情報を格納するための格納手段を備え、
   前記メディアコンテンツにおける特定の時間位置へのジャンプ指示を受けたときに、当該メディアコンテンツに対応する前記インデックス情報が前記格納手段にない場合に、前記ストリーミングメディア配信装置から前記インデックス情報を取得し、当該取得したインデックス情報を参照することにより、前記特定の時間位置を含むセグメントを特定し、当該セグメントにおいて前記特定の時間位置に最も近い先頭を持つGOPのデータ位置を特定し、当該データ位置の特定がなされたGOPのデータと、それ以降のデータを前記ストリーミングメディア配信装置に順次要求して取得するメディアデータ取得処理ステップと、
   前記メディアデータ取得処理ステップにより取得されたメディアデータを順次再生する再生ステップと
   を備えたことを特徴とするストリーミングメディア再生方法。
3. コンピュータを、請求項１に記載のストリーミングメディア再生装置のメタ情報取得手段、メディアデータ取得処理手段、及び再生手段として機能させるためのプログラム。
   

Images