(57)【特許請求の範囲】
【請求項１】
配信サーバから映像データをチャンク単位で端末に対して配信する映像配信方式において、端末における映像データの再生状態を推定する映像再生状態推定装置であって、
前記映像データのキャプチャデータから取得された各チャンクのチャンク長に基づいて各チャンクの画質を推定する画質推定手段と、
前記映像データにおけるチャンクの観測時刻毎にチャンクを順次仮想的バッファに蓄積し、当該仮想的バッファ内チャンクの中で観測時刻が最も早いチャンクを再生対象とし、当該チャンクの持続時間経過後に当該チャンクを消去するとともに、当該チャンクの持続時間を当該チャンクに対応する画質の映像が再生されている時間として、当該時間の情報と画質とを記憶部に蓄積するバッファ処理手段と
を備えることを特徴とする映像再生状態推定装置。
【請求項２】
前記画質推定手段は、画質とチャンク長の範囲とを対応付けたデータと、前記各チャンクのチャンク長とに基づいて各チャンクの画質を推定する
ことを特徴とする請求項１に記載の映像再生状態推定装置。
【請求項３】
前記バッファ処理手段は、順次仮想的バッファに蓄積されるチャンクの画質が変更されたときに、画質変更前後の画質の組み合わせに応じて予め定めた数まで残存する画質変更前チャンクを再生した後に、画質変更後のチャンクを再生対象とする
ことを特徴とする請求項１又は２に記載の映像再生状態推定装置。
【請求項４】
前記予め定めた数が０である場合、前記バッファ処理手段は、変更後の画質のチャンクを観測した時刻に再生中のチャンクを持続時間経過により消去した直後に、仮想的バッファ内チャンクを全てクリアし、前記変更後の画質のチャンクを再生対象とする
ことを特徴とする請求項３に記載の映像再生状態推定装置。
【請求項５】
前記キャプチャデータにおけるＴＣＰパケットのヘッダ情報に基づいて、前記各チャンクの観測時刻を推定する手段を備える
ことを特徴とする請求項１ないし4のうちいずれか1項に記載の映像再生状態推定装置。
【請求項６】
配信サーバから映像データをチャンク単位で端末に対して配信する映像配信方式において、端末における映像データの再生状態を推定する映像再生状態推定装置が実行する映像再生状態推定方法であって、
前記映像データのキャプチャデータから取得された各チャンクのチャンク長に基づいて各チャンクの画質を推定する画質推定ステップと、
前記映像データにおけるチャンクの観測時刻毎にチャンクを順次仮想的バッファに蓄積し、当該仮想的バッファ内チャンクの中で観測時刻が最も早いチャンクを再生対象とし、当該チャンクの持続時間経過後に当該チャンクを消去するとともに、当該チャンクの持続時間を当該チャンクに対応する画質の映像が再生されている時間として、当該時間の情報と画質とを記憶手段に蓄積するバッファ処理ステップと
を備えることを特徴とする映像再生状態推定方法。
【請求項７】
コンピュータを、請求項１ないし５のうちいずれか１項に記載の映像再生状態推定装置における各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動的レート制御を行うプログレッシブダウンロード型映像配信において、配信経路上でパッシブに取得したパケットキャプチャデータに基づき再生状態推定を行う技術に関連するものである。
【背景技術】
【０００２】
近年、通信網の広帯域化が進んでおり、より多くのトラヒックがインターネットを介して流通するようになった。特に大きなファイルサイズを持つコンテンツをダウンロードしながらデータ処理を並行して行う、プログレッシブダウンロード型のコンテンツ配信システムが普及している。このようなコンテンツ配信システムでは、ネットワークを介することによる遅延変動やパケットロス、再送等によりデータが一定速度で端末に到着せず、データの到着には送信タイミングに対して揺らぎが発生する。そのため、端末側でその揺らぎを吸収するために、再生バッファを用意し、ネットワークの影響を上位アプリケーションに対して隠ぺいする仕組みが用いられることが多い。
【０００３】
このようなコンテンツ配信システムでは、一時的にネットワークのスループットがコンテンツデータの処理速度よりも低くなる場合には、再生バッファが一定量（再生停止閾値）を下回り、再生が停止されることがある。この再生停止は、当該コンテンツのユーザ体感品質に大きな影響を与えるため、コンテンツの再生停止状態等の再生状態を推定する技術が必要とされ、種々の技術が提案されている（例えば、非特許文献１〜３）。
【０００４】
プログレッシブダウンロード型のコンテンツ配信では、単一のコンテンツであっても、複数の単位に分割して配信を行う形態が多い。分割された各単位をチャンクと呼び、このような配信方式をチャンク型のコンテンツ配信方式と呼ぶ。チャンク型のコンテンツ配信の動作イメージを図１に示す。図１に示すとおり、受信したパケットからチャンクを取得し、チャンク単位で再生バッファに格納され、再生（デコード）される。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】池上大介、本多泰理、山本浩司他：「プログレッシブダウンロード系サービスの停止時間推定法」信学技報, vol. 111, no. 278, CQ2011-59, pp. 91-96, 2011 年 11 月.
【非特許文献２】池上大介、本多泰理、山本浩司：「チャンク型映像配信サービスにおける再生状態推定法の検討」、電子情報通信学会総合大会、B-11-24,2012 年 3 月.
【非特許文献３】本多泰理、池上大介、山本浩司：「Ack 観測による映像再生状態推定法の検討 」、電子情報通信学会総合大会,B-11-25，2012 年 3 月.
【非特許文献４】Z.I.Botev, J.F.Grotowski, and D.P.Kroese, Kernel density estimation via diffusion, Ann. Statist. 38(2010), 2916-2957.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１〜３に記載された従来技術では、パケットキャプチャデータから端末の受信バイト量時系列を把握し、端末の再生バッファを模擬した仮想的なバッファモデルへ入力することで再生状態の推定を実現している。これらの技術を利用することにより、所与のパケットキャプチャデータから、個々のセッションの映像の再生状態を推定可能である。
【０００７】
一方で近年、モバイル端末やタブレット端末の普及に伴い、パソコンよりも低スペックの端末で、3GやLTE 等の無線アクセスによりプログレッシブダウンロード型映像を視聴する利用形態が増大している。この場合、ユーザの移動や電波のフェージングに伴うネットワーク環境の劣化により、再生状態劣化が頻発する状況も珍しくない。このため、環境に応じてレートを増減させ、アダプティブに映像配信を行う技術が確立され、国際標準化の場でも議論されている。当該技術は、例えば配信経路上の往復遅延等の推定に基づき、配信サーバ側でコンテンツの画質（デコードレート）を動的に増減させ、再生停止の抑止と映像品質確保のトレードオフ解決を目的としている。
【０００８】
しかしながら、非特許文献１〜３に記載された従来技術は、こうしたアダプティブなレート制御を行う映像配信には対応していない。
【０００９】
本発明は上記の点に鑑みてなされたものであり、アダプティブなレート制御を行う映像配信サービスにおいても、適切に映像再生状態を推定することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一実施形態によれば、配信サーバから映像データをチャンク単位で端末に対して配信する映像配信方式において、端末における映像データの再生状態を推定する映像再生状態推定装置であって、
前記映像データのキャプチャデータから取得された各チャンクのチャンク長に基づいて各チャンクの画質を推定する画質推定手段と、
前記映像データにおけるチャンクの観測時刻毎にチャンクを順次仮想的バッファに蓄積し、当該仮想的バッファ内チャンクの中で観測時刻が最も早いチャンクを再生対象とし、当該チャンクの持続時間経過後に当該チャンクを消去するとともに、当該チャンクの持続時間を当該チャンクに対応する画質の映像が再生されている時間として、当該時間の情報と画質とを記憶部に蓄積するバッファ処理手段とを備えることを特徴とする映像再生状態推定装置が提供される。
【発明の効果】
【００１１】
本発明の一実施形態によれば、アダプティブなレート制御を行う映像配信サービスにおいても、適切に映像再生状態を推定することを可能とする技術が提供される。
【図面の簡単な説明】
【００１２】
【図１】チャンク型配信の動作イメージを示す図である。
【図２】本発明の実施の形態に係る映像再生状態推定装置１００の機能構成図である。
【図３】本発明の実施の形態に係る映像再生状態推定装置２００の機能構成図である。
【図４】チャンク長密度推定部１により得られる各画質に属するチャンク長の基本領域及び確率密度関数を描画した例を示す図である。
【図５】画質判定の手順１を示すフローチャートである。
【図６】画質判定の手順１、手順２を行った場合の画質の例を示す図である。
【図７】バッファ処理部３の処理を示すフローチャートである。
【図８】画質変更がある場合のバッファ処理例を示す図である。
【図９】再生状態推定結果の例を示す図である。
【図１０】例１（ダウンロード方向）において、チャンクの取得時刻推定部２３２が取得するシーケンス番号の例を示す図である。
【図１１】例１における処理のシーケンス図である。
【図１２】例１の判定例を示す図である。
【図１３】例２（アップロード方向）において、チャンクの取得時刻推定部２３２が取得するＡｃｋ番号の例を示す図である。
【図１４】例２における処理のシーケンス図である。
【図１５】例２の判定例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。また、以下の実施の形態で示される具体的な数値は一例であり、それに限定されるわけではない。
【００１４】
以下の説明において、αは各画質のチャンク長の基本領域間のマージンを表す。Nは対象とするサービスに設定されている画質レベル数を表す。例えば、対象とするサービスに設定されている画質が高画質、中画質、低画質の３つである場合はN=3である。Mはパケットキャプチャデータ中のチャンク数を表す。Nijはバッファ処理において、画質iから画質jへの変更時に仮想バッファモデル内で画質iの再生されるチャンク数である。
【００１５】
（装置構成）
＜映像再生状態推定装置１００＞
図２に、本発明の実施の形態に係る映像再生状態推定装置１００の機能構成図を示す。図２に示すように、本実施の形態に係る映像再生状態推定装置１００は、チャンク長密度推定部１、画質変更検知部２、判定結果蓄積部２１、バッファ処理部３、及び再生状態蓄積部３１を備える。本装置の利用者としては、例えば当該サービスを提供するネットワーク事業者や、サービスプロバイダを想定する。映像再生状態推定装置１００の各機能部の動作の詳細については後述するが、概要は以下のとおりである。
【００１６】
チャンク長密度推定部１は、対象とするサービスの画質レベル数、各画質のチャンク長分布観測値（度数分布）、及びマージンパラメータαを入力とし、各画質に属するチャンク長の基本領域及び確率密度関数を出力する。
【００１７】
画質変更検知部２は、パケットキャプチャデータのチャンク情報（チャンク毎のチャンク長（バイト量）、チャンク観測時刻等）、及び各画質に属するチャンク長の基本領域及び確率密度関数を入力とし、チャンク毎の画質を推定（判定）し、判定結果（チャンク毎の画質）を出力する。画質変更検知部２により出力された判定結果は判定結果蓄積部２１に蓄積される。判定結果蓄積部２１には、例えば、チャンク番号と当該チャンクの画質が蓄積される。なお、画質変更検知部２は、画質を推定する機能部であるから、画質推定部と称してもよい。
【００１８】
バッファ処理部３は、パケットキャプチャデータのチャンク情報（チャンク毎のチャンク長、チャンク観測時刻等）、チャンク毎の画質、画質変更時の旧画質の残存チャンク数行列（Nij）、各画質の単一チャンクあたりの持続時間（再生時間長）、及び視聴終了時刻TEを入力とし、再生状態を推定し、推定した再生状態を出力する。出力された再生状態は再生時刻情報とともに再生状態蓄積部３１に蓄積される。
【００１９】
本実施の形態では、映像再生状態推定装置１００がチャンク長密度推定部１を含み、映像再生状態推定装置１００において各画質に属するチャンク長の基本領域及び確率密度関数を求めることとしているが、映像再生状態推定装置１００がチャンク長密度推定部１を含まないこととしてもよい。すなわち、映像再生状態推定装置１００の外部で各画質に属するチャンク長の基本領域及び確率密度関数を求め、これらを入力として映像再生状態推定装置１００に与えてもよい。
【００２０】
＜映像再生状態推定装置２００：チャンク状態推定部を含む例＞
また、本実施の形態では、映像再生状態推定装置１００の外部でパケットをキャプチャし、キャプチャデータからチャンク長やチャンク観測時刻等のチャンク情報を算出し、算出した値を映像再生状態推定装置１００に入力として与えることとしているが、映像再生状態推定装置１００がパケットをキャプチャし、キャプチャデータからチャンク情報を算出する機能を含むこととしてもよい。その場合の装置構成の例（映像再生状態推定装置２００と表記）を図３に示す。図３では、図２の映像再生状態推定装置１００に相当する機能部を映像再生状態推定部１００と表記している。
【００２１】
同図に示す映像再生状態推定装置２００は、チャンク単位の配信を行う配信サーバ３００と端末４００に接続されており、パケットデータ取得部２１０、記憶部２２０、チャンク状態推定部２３０、及び映像再生状態推定部１００を有する。端末４００は、少なくとも再生バッファと再生アプリケーションを有する。
【００２２】
本実施の形態において、配信サーバ３００と端末４００はＴＣＰ／ＩＰにより通信を行い、配信サーバ３００は、端末４００に対して、一つのコンテンツを複数のチャンク単位に分割して配信する。また、レイヤ４で見ると、チャンクは分割され、それぞれパケット（セグメント）として端末４００に送信される。
【００２３】
端末４００は、再生バッファを有し、当該再生バッファに、所定のチャンク数が蓄積されると、再生を開始し、再生中は、当該再生バッファから再生に必要なデータを読み出し、再生バッファに蓄積されたチャンク数が再生停止閾値を下回ると再生が停止し、再生開始閾値を上回ると再生が開始する機能を有する。
【００２４】
パケットデータ取得部２１０は、配信サーバ３００から端末４００に対して配信されるパケットデータ（ＴＣＰパケットのヘッダ情報も含む）を取得し、記憶部２２０に格納する。また、本実施の形態では、パケットデータ取得部２１０は、端末４００から配信サーバ３００に送信されるＴＣＰのＡｃｋパケットも取得し、記億部２２０に格納する。なお、Ａｃｋパケットを広い意味でＴＣＰパケットと称してもよい。
【００２５】
チャンク状態推定部２３０は、チャンクの時間長推定部２３１とチャンクの取得時刻推定部２３２を有する。
【００２６】
チャンクの時間長推定部２３１は、記憶部２２０に格納されたパケットデータや、予め既知のコンテンツ規則等の情報に基づいて、各チャンクの再生時間長（持続時間）のリストを作成する。再生時間長のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。
【００２７】
チャンクの取得時刻推定部２３２は、記憶部２２０に格納されているパケットデータから、各チャンクの受信が完了した時刻を推定し、各チャンクの取得時刻（観測時刻とも呼ぶ）のリストを作成し、メモリ等に格納する。取得時刻のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた２次元の配列として保持してもよい。なお、ここで推定した取得時刻から、チャンク毎のチャンク長（バイト量）を算出することもできる。
【００２８】
本実施の形態では、チャンクの取得時刻推定部２３２は、ＴＣＰヘッダ情報を利用することにより、各チャンクの取得時刻を推定するが、詳細は後述する。
【００２９】
なお、映像再生状態推定装置２００は、パケットデータ取得部２１０、記憶部２２０、チャンク状態推定部２３０、及び映像再生状態推定部１００を有する構成であるが、これ以外にも、映像再生状態推定装置１００（図２）にチャンク状態推定部２３０を追加した構成としてもよい。つまり、この場合、パケットデータのキャプチャを外部で行い、映像再生状態推定装置１００は、チャンク状態推定、及び映像再生状態推定を行う。
【００３０】
本実施の形態に係る映像再生状態推定装置は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、映像再生状態推定装置の各部が有する機能は、当該映像再生状態推定装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００３１】
（映像再生状態推定装置１００の動作例）
以下、映像再生状態推定装置１００（図２）の動作例を詳細に説明する。
【００３２】
＜チャンク長密度推定部１＞
本装置の利用者は、対象とするサービスの画質数、各画質のチャンク長分布観測値（度数分布）、及びマージンパラメータαをチャンク長密度推定部１に入力する。これらの値は観測等により予め得られている値である。
【００３３】
チャンク長密度推定部１は、まず、各画質に属するチャンク長 (バイト量) につき、重複が無いように基本領域を設定する。すなわち、画質数Nとし、画質i (i = 1, 2, . . . , N) の基本領域をそれぞれKi = [ai, bi] (i = 1, 2, . . ., N) とする。つまり、画質iのチャンク長は、ai以上かつbi以下である。ここで、以下の記述の簡易性のため、画質iはチャンク長の降順とする。すなわち、i の値が小さいほど（画質が良いほど）、チャンク長が長く、b1 ≧ a1 ≧ b2 ≧ a2 . . .  bN ≧ aNを満たすものとする。
【００３４】
また、マージンパラメータαによりai+1 - bi ≧ α(i = 1, 2, . . . , N - 1) が成り立つようにする。基本領域は各画質間で重複しない閉区間として設定されていることに留意する。
【００３５】
チャンク長密度推定部１は更に、各画質に属するチャンク長の確率密度関数を滑らかな関数として推定する。当該手法は、カーネル密度関数による推定を適用してもよいし、非特許文献４に見られる手法を適用してもよい。
【００３６】
チャンク長密度推定部１は、以上の過程により得られた、各画質に属するチャンク長の基本領域及び確率密度関数を出力する。なお、上記工程は事前に本装置の外部で行い、結果を画質変更検知部２への入力とすることも可能である。
【００３７】
図４に、チャンク長密度推定部１により得られる各画質に属するチャンク長の基本領域及び確率密度関数を描画した例を示す。図４に示す例は、N = 3（高画質、中画質、低画質）の例であり、マージンパラメータα= 10[kbyte] にとり、基本領域は、高画質I1 = [200, 300]、中画質I2 = [100, 150]、低画質I3 = [50, 90]である（いずれも単位は [kbyte]）。
【００３８】
＜画質変更検知部２：手順１＞
次に、画質変更検知部２は、パケットキャプチャデータのチャンク情報（チャンク長、観測時刻等）、及び、前記各画質に属するチャンク長の基本領域及び確率密度関数を入力として、次のようにして画質変更箇所を検知する。これを手順１とする。
【００３９】
以下、当該データ中の総チャンク数をMとする。当該データ中で、画質変更検知部２は、各チャンク長を観測時刻順に取得し、j (j = 1, 2, . . ., M)番目のチャンクのチャンク長ljについて、図５のフローチャートに示す手順に従って画質判定を行う。
【００４０】
lj ≧ b1である場合（ステップ１０１のＹｅｓ）、すなわち、チャンク長ljが最高画質の基本領域の最大チャンク長以上である場合には当該チャンクの画質Q(j)を１とする（ステップ１０２）。lj ≦ aNである場合（ステップ１０１のＮｏ、ステップ１０３のＹｅｓ）、すなわち、チャンク長ljが最低画質の基本領域の最小チャンク長以下である場合には当該チャンクの画質をNとする（ステップ１０４）。
【００４１】
ステップ１０３においてＮｏの場合、チャンクがいずれかの基本領域に属するかどうか判定する（ステップ１０５）、すなわち、下記の画質i0が存在するかどうか判定する。
【００４２】
【数１】
0006053176.tif 000002
i0が存在する場合（ステップ１０５のＹｅｓ）、チャンクjは画質i0に該当すると判定する（ステップ１０６）。本判定ルールで判定不能な場合には「判定不能」とする（ステップ１０７）。
【００４３】
画質変更検知部２は、各チャンクに対する前記判定結果を、チャンク毎にチャンクの観測時刻順に判定結果蓄積部２１に蓄積する。
【００４４】
＜画質変更検知部２：手順２＞
本実施の形態において、画質変更検知部２は、上記の判定ルール（手順１）で判定不能であったチャンクに対し、以下のようにして画質の最尤判定を行う。これを手順２とする。
【００４５】
画質変更検知部２は、判定結果蓄積部２１に蓄積された手順１の判定結果から、手順１で画質が判定できないチャンクの連結成分を抽出する。ここで連結成分とは、番号が連続するチャンクを意味する。例えば、手順１で画質が判定不能であったチャンクの番号を仮に{2, 3, 5, 6, 7}とすると、連結成分は(2, 3)及び (5, 6, 7)の２成分である。
【００４６】
画質変更検知部２は、手順１で判定結果が未定のチャンクの連結成分毎に、下記手順を実施する。
【００４７】
ある単一の連結成分に属するチャンクがm個（mは１以上）として、当該チャンクの番号を
【００４８】
【数２】
0006053176.tif 000003
で表す。これらの各チャンクについて、それぞれ画質を振らせ、チャンク長確率密度推定部１で算出した確率密度関数に基づき、確率密度を算出する。
【００４９】
例えば、チャンクClのチャンク長が、画質qに属するとした時の確率密度を f (l; q) と表す。また、チャンクClの推定画質をQ(l)で表す。この時、チャンクの組
【００５０】
【数３】
0006053176.tif 000004
に対する最も確からしい画質の組合せ Q : l → Q(l) を、以下の目的関数を最小化するように選択する：
【００５１】
【数４】
0006053176.tif 000005
ただし、ci (i = 1, 2, . . .     , 4) は重み付け定数、Q(0), Q(m + 1) はそれぞれ当該連結成分前後の画質決定チャンクの画質である。
【００５２】
上記手順１、手順２により、画質変更検知部２はキャプチャデータ中の各チャンクの推定画質を全チャンクについて算出することができる。画質変更検知部２は、チャンク毎のチャンク観測時刻順にチャンク毎の画質を出力する。
【００５３】
図６（ａ）に、手順１で判定結果蓄積部２１に蓄積された各チャンクの画質判定結果例を示す。本結果に、手順２の式で定義される最尤推定を施した結果、図６(ｂ) に示す判定結果を得る。ただし、本例ではci = 1 (i = 1, 12, 3, 4) とした。例えば、図６（ａ）のC0、C1、C2、C3、C4で示すチャンクにおいて、C1、C2、C3の画質が判定不能であったところ、手順２の最尤推定により、図６（ｂ）に示すように、C1、C2、C3の画質が推定されている。
【００５４】
上記のように、画質変更検知部２は、画質とチャンク長の範囲とを対応付けたデータ（前述した基本領域等）と、各チャンクのチャンク長とに基づいて各チャンクの画質を推定する。
【００５５】
＜バッファ処理部３＞
続いて、バッファ処理部３の動作を説明する。バッファ処理部３への入力は、パケットキャプチャデータのチャンク情報（チャンク毎の観測時刻等）、チャンク毎の画質、各画質の単一チャンクあたりの持続時間（再生時間長）、画質変更時の旧画質の残存チャンク数の行列 {Nij} (i, j = 1, 2, . . . , N )(画質iから画質jへの変更時)、及び視聴終了時刻TEである。TEはパケットキャプチャ開始時刻（つまり、チャンク取得開始時刻）を0とした時の、視聴終了時刻を表す。
【００５６】
バッファ処理部３は仮想的なバッファ（仮想的バッファモデル）を有する。バッファ処理部３は、パケットキャプチャデータ中のチャンクの観測時刻に当該チャンクを仮想的バッファモデルに入力して蓄積し、前記入力された各チャンクの持続時間に基づきバッファ内チャンク数を推定し、s秒毎に再生状態（本例では、再生中チャンクの画質もしくは再生停止状態）を再生状態蓄積部３１に記録する。ここで各チャンクの持続時間は、画質毎に異なっていてもよい。
【００５７】
バッファモデルに蓄積された各チャンクは、到着順に前記入力された持続時間経過後に消滅するが、チャンク消費中の時間をもって当該画質の映像が再生されている時間として、つまり、再生中として、再生状態蓄積部３１に記録していく。この処理をチャンクの観測時刻順に実施していくことで、端末の再生バッファ内のチャンク数や再生状態を推定することができる。すなわち、バッファ処理部３は、映像データにおけるチャンクの観測時刻毎にチャンクを順次仮想的バッファに蓄積し、当該仮想的バッファ内チャンクの中で観測時刻が最も早いチャンクを再生対象とし、当該チャンクの持続時間経過後に当該チャンクを消去するとともに、当該チャンクの持続時間を当該チャンクに対応する画質の映像が再生されている時間として、当該時間の情報と画質とを再生状態蓄積部３１に蓄積する。
【００５８】
図７に、バッファ処理部３の処理フローを示す。図７に示すように、iを現在までの到着チャンク数とし、jを現在までの消去チャンク数とし、tを現在時刻とし、dを次回のチャンク消去時刻とし、stを再生状態（本例では、再生中チャンクの画質もしくは再生停止状態）とし、chをバッファ内チャンク数とする。
【００５９】
バッファ処理部３は、変数を初期化する（ステップ２０１）。そして、再生状態記録時刻（s秒毎）、チャンク消去時刻(d)、新たなチャンク到着時刻（ti+1）のいずれかが到来する度にそれぞれに対応する処理を行う（ステップ２０２）。
【００６０】
現在時刻が再生状態記録時刻のときには、現在の再生状態（st）を現在時刻とともに再生状態蓄積部３１に記録する（ステップ２０３）。
【００６１】
ステップ２０４のチャンク消去時刻では、バッファ内チャンクが存在する場合（chが正の場合）に、バッファに存在するチャンクの中で到着時刻が最も早いチャンクを消去する。つまり、バッファ内チャンク数を１減算し、現在までの消去チャンク数を１増加させる。更に、チャンク消去後にバッファに存在するチャンクの中で到着時刻が最も早いチャンクの消去時刻を次回のチャンク消去時刻dとする。そして、再生状態stに、再生中のチャンク（次に消去することになるチャンク）の画質を入れる。チャンク消去後にもしもチャンク数が０であれば再生状態stは「停止状態」となる。
【００６２】
なお、チャンク消去時刻はチャンクの持続時間から求められる。例えば、チャンク１が時刻Tで消去された時点で、バッファに存在するチャンクの中で到着時刻が最も早いチャンク２の持続時間がRであるとすると、次のチャンク消去時刻はT+Rである。
【００６３】
ステップ２０５のチャンク到着時刻では、新たに到着したチャンクの画質が、その前に到着したチャンクの画質から変更がない場合（ステップ２０５のＮｏ）、バッファ内チャンク数を１増加させ、現在までの到着チャンク数を１増加させる。更に、バッファに存在するチャンクの中で到着時刻が最も早いチャンクの消去時刻を次回のチャンク消去時刻dとする（ステップ２０６）。なお、チャンク到着時に、既にバッファ内にチャンクが存在していた場合、チャンク到着時には次回のチャンク消去時刻dに変更はない。
【００６４】
チャンク到着時刻において、新たに到着したチャンクの画質が、その前に到着したチャンクの画質から変更されている場合（ステップ２０５のＹｅｓ）、当該新たな画質のチャンクが観測された時刻において、当該時刻にバッファ内に残存する旧画質のチャンクを当該時刻に再生中のチャンクの次のチャンクから数えてNij個まで再生後、新たな画質に変更する（ステップ２０７）。Nij = 0 の場合は、新たな画質のチャンクが観測された時刻に再生中のチャンクの再生終了次第、バッファ内のチャンクを全クリアし、新たな画質のチャンクの再生を開始する。
【００６５】
各時刻における再生中チャンクの画質を時刻情報と共に再生状態蓄積部３１に記録する動作は、前記と同様である。
【００６６】
上記のように、バッファ処理部３は、順次仮想的バッファに蓄積されるチャンクの画質が変更されたときに、画質変更前後の画質の組み合わせに応じて予め定めた数まで残存する画質変更前チャンクを再生した後に、画質変更後のチャンクを再生対象とする。また、予め定めた数が０である場合、バッファ処理部３は、変更後の画質のチャンクを観測した時刻に再生中のチャンクを持続時間経過により消去した直後に、仮想的バッファ内チャンクを全てクリアし、前記変更後の画質のチャンクを再生対象とする。
【００６７】
図８（ａ）、（ｂ）に、画質変更がある場合のバッファ処理例を示す。図 ８（ａ）は、画質１から画質２への変更の例を示しており、画質１のチャンク１０を再生中に画質２のチャンクが到着し、再生中のチャンク１０からチャンク１２まで再生後、新たな画質に変更することを示している。これはN12 = ２の場合である。
【００６８】
図８（ｂ）は、画質２から画質１への変更の例を示しており、画質２のチャンク１１を再生中に画質１のチャンクが到着し、画質２のチャンク１１の再生終了次第、バッファ内のチャンクを全クリアし、画質１のチャンクの再生を開始する。これはN21 = ０の場合である。すなわち、図８（ａ）、（ｂ）の例は、高画質への遷移時の方が、より速くバッファ内チャンクが消費される動作となっている。
【００６９】
以上の様にして、視聴終了時刻TEまで再生状態を再生状態蓄積部３１に記録していく。また、チャンクダウンロード終了時刻よりもTEが大きい場合、すなわちダウンロード終了後も視聴を継続した場合については、最後のチャンクダウンロード時刻において再生状態であった場合には、バッファ内チャンクが枯渇するまで再生状態として再生状態蓄積部３１に記録する。
【００７０】
仮にチャンクダウンロード終了時刻の直後の時点において再生停止状態であった場合には、再生停止状態が継続するため、視聴終了時刻TEを末尾として、その間の状態を全て「再生停止」として再生状態蓄積部３１に記録する。
【００７１】
図９に、バッファ処理部３の出力であり、再生状態蓄積部３１に記録される再生状態推定結果の例を示す。図９に示すように、実態値との比較の結果、高精度で再生状態を推定できていることが確認できる。
【００７２】
（チャンクの取得時刻推定部２３２の動作例）
本発明において、パケットキャプチャデータからどのようにしてチャンクの取得時刻（観測時刻）を推定するかは特定の方法に限定されず、例えば、ＨＴＴＰ  ＧＥＴ信号からチャンクの取得時刻を推定できる。しかし、ＨＴＴＰＳ等により、Ｌ７での暗号化措置が講じられた際には、ＨＴＴＰ  ＧＥＴ信号の情報を把握できないといった問題があるため、本実施の形態では、ＴＣＰヘッダ情報を利用することにより、各チャンクの取得時刻を推定することとしている。この動作は、図３に示したチャンクの取得時刻推定部２３２により実行される。
【００７３】
チャンクの取得時刻推定部２３２は、パケットデータ取得部２１０により取得されたＴＣＰパケット（レイヤ４）の情報を用いてチャンクダウンロード完了タイミングを判定し、当該タイミングの時刻をチャンクの取得時刻とする。ＴＣＰパケットの情報を用いてチャンクダウンロード完了タイミングを判定する方法として、本実施の形態では、以下の２つの例について説明する。なお、ここでの「ＴＣＰパケット」とは、ＴＣＰヘッダとＴＣＰペイロードを含むパケットを意味する。
【００７４】
＜例１：シーケンス番号を用いる例＞
例１は、ダウンロード方向（配信サーバ３００−＞端末４００）のＴＣＰパケットのヘッダからシーケンス番号を取得し、当該シーケンス番号がある定数で増え続けている場合はチャンクダウンロード中と判断し、定数以外の増え方をした際にチャンクダウンロードが完了したと判定するものである。
【００７５】
ＴＣＰによるパケットは、その経路上で通過可能な最大パケットサイズで構成される事から、あるチャンクをダウンロードしている最中では、ＴＣＰパケットのペイロード長は一定であり、最大ペイロード長となる。そして、チャンクをダウンロードする最後のＴＣＰパケットのみがそれまでとは異なるペイロード長となる。なお、ＴＣＰパケットにおいて、最大ペイロード長は、（ＭＴＵ（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）−ヘッダ長）として、ヘッダ情報から算出できる値である。ＭＴＵは、１回の転送で送信できるデータの最大値を示す値である。例えばＥｔｈｅｒｎｅｔ（登録商標）の場合、ＭＴＵが１５００でヘッダ長が４０であるため、最大ペイロード長は１４６０である。
【００７６】
例１では、上記の特徴を活用して、ＴＣＰパケットのシーケンス番号の増加が不均一となるパケットをもってチャンクダウンロードが完了したと判断する。
【００７７】
ＴＣＰパケットのシーケンス番号は、当該ＴＣＰパケットに格納したデータ（ペイロード）の先頭が、送信データの何バイト目に相当するかを示す番号である。従って、上記のように、最大ペイロード長のデータを順次配信している場合は、シーケンス番号は最大ペイロード長ずつ増加する。しかし、パケットに分割されたチャンクの最後の部分では、データが最大ペイロード長よりも短くなるから、最大ペイロード長だけ増加しないことになる。なお、チャンクサイズが最大ペイロード長の整数倍の場合には、本方式は適用することができない。
【００７８】
以下、図１０、図１１、図１２を参照して、例１におけるチャンクの取得時刻推定部２３２の動作を説明する。
【００７９】
チャンクの取得時刻推定部２３２は、記憶部２２０に格納された、ダウンロード方向のＴＣＰパケットを時系列で順次参照し、ヘッダからシーケンス番号を取得する。例えば、チャンクの取得時刻推定部２３２は、図１０に示すようにパケット毎のシーケンス番号を取得する。
【００８０】
上記の動作を前提に、チャンクの取得時刻推定部２３２は、図１１に示すシーケンス図の手順でチャンクダウンロード完了判定処理を行う。
【００８１】
チャンクの取得時刻推定部２３２は、最大ペイロード長を取得する（ステップ３１１）。なお、最大ペイロード長の取得は、ＴＣＰパケット受信の度に毎回行う必要はなく、例えば、所定のパケット数毎、ＴＣＰ接続毎に行うこと等が考えられる。
【００８２】
続いて、チャンクの取得時刻推定部２３２は、現在対象としているＴＣＰパケットのシーケンス番号から１つ前のＴＣＰパケットのシーケンス番号を引くことにより、増加値、すなわち当該ＴＣＰパケットのペイロード長を算出する（ステップ３１２）。
【００８３】
そして、チャンクの取得時刻推定部２３２は、ステップ３１２で算出したペイロード長と最大ペイロード長とを比較し、これらが一致するか否か（同値であるか否か）を調べ（ステップ３１３）、一致する場合（ステップ３１３のＹｅｓ）は次のＴＣＰパケットのシーケンス番号を取得し、それを現在のシーケンス番号としてステップ３１２からの処理を繰り返す。
【００８４】
ペイロード長と最大ペイロード長とが一致しない場合、すなわち、増加値と最大ペイロード長とが一致しない場合（ステップ３１３のＮｏ）は、チャンクダウンロード完了と判定し（ステップ３１４）、チャンクの取得時刻推定部２３２は、例えば、そのときのＴＣＰパケットのキャプチャ時刻（タイムスタンプから取得できる）をチャンク取得時刻としてメモリ等の記憶手段に保持する。
【００８５】
例えば、図１０に示した入力情報の例において、図１２に示すように、パケット１５まで一定値（１４１６バイト）で増加するが、パケット１６は、パケット１５から７１２バイト（≠１４１６バイト）だけしか増加していないから、パケット１６の受信タイミングをチャンクのダウンロード完了タイミングと判定する。
【００８６】
＜例２：確認応答（Ａｃｋ）番号を用いる例＞
例２は、アップロード方向（端末４００−＞配信サーバ３００）のＴＣＰパケットのヘッダからＡｃｋ番号を取得し、Ａｃｋ番号がある定数の整数倍（ここでの整数とは１以上の整数である）で増え続けている場合はチャンクダウンロード中と判定し、整数倍以外の増え方をした際にチャンクダウンロードが完了したと判定するものである。
【００８７】
ＴＣＰ通信では、パケットの受信側（端末４００）は、受信パケットのシーケンス番号に、受信したデータ（ペイロード）のバイト数を加算したＡｃｋ番号を含むＴＣＰパケット（Ａｃｋパケットと呼ぶ）を返す動作を行う。ただし、ＴＣＰ通信では、遅延応答（Ｄｅｌａｙｅｄ  ＡＣＫ）と呼ばれる、複数パケット分の応答をまとめて返すモードがある。例えば、２パケット分のＡｃｋ番号を返す場合は、２パケットのうちの最初に受信したパケットのシーケンス番号に、２パケット分のペイロード長が加算された番号がＡｃｋ番号として返される。
【００８８】
例１で説明したとおり、チャンクダウンロード中は、ＴＣＰパケットのシーケンス番号は、最大ペイロード長で均一に増加していくので、１つ１つのパケットにＡｃｋを返す場合は、Ａｃｋ番号は最大ペイロード長ずつ増加し、複数パケットに対してまとめてＡｃｋを返す場合は、最大ペイロード長の整数倍（パケットの個数分）だけ増加することになる。よって、上記のように、例２では、Ａｃｋ番号がある定数の整数倍（ここでの整数とは１以上の整数である）で増え続けている場合はチャンクダウンロード中と判定し、整数倍以外の増え方をした際にチャンクダウンロードが完了したと判定するのである。
【００８９】
以下、図１３、図１４、図１５を参照して、例２におけるチャンクの取得時刻推定部２３２の動作を説明する。
【００９０】
チャンクの取得時刻推定部２３２は、記憶部２２０におけるアップロード方向のＡｃｋパケットを時系列で順次参照し、ヘッダからＡｃｋ番号を取得する。例えば、チャンクの取得時刻推定部２３２は、図１３に示すようにパケット毎のＡｃｋ番号を取得する。
【００９１】
上記の動作を前提に、チャンクの取得時刻推定部２３２は、図１４に示すシーケンス図の手順でチャンクダウンロード完了判定処理を行う。
【００９２】
チャンクの取得時刻推定部２３２は、最大ペイロード長を取得する（ステップ３２１）。なお、最大ペイロード長の取得は、Ａｃｋパケット取得の度に毎回行う必要はなく、例えば、所定のパケット数毎、ＴＣＰ接続毎に行うこと等が考えられる。
【００９３】
続いて、チャンクの取得時刻推定部２３２は、現在対象としているＡｃｋパケットのＡｃｋ番号から１つ前のＡｃｋパケットのＡｃｋ番号を引くことにより、Ａｃｋ番号の増加値を算出する（ステップ３２２）。この増加値は、前回のＡｃｋパケット送信時以降、今回のＡｃｋパケット送信までに受信したパケットのペイロード長の合計に相当する。
【００９４】
そして、チャンクの取得時刻推定部２３２は、ステップ３２２で算出した増加値と最大ペイロード長とを比較し、増加値が最大ペイロード長の整数（１以上の整数）倍であるか否かを調べ（ステップ３２３）、整数倍である場合（ステップ３２３のＹｅｓ）は次のＡｃｋパケットのＡｃｋ番号を取得し、それを現在のＡｃｋ番号としてステップ３２２からの処理を繰り返す。
【００９５】
増加値が最大ペイロード長の整数倍でない場合（ステップ３２３のＮｏ）は、チャンクダウンロード完了と判定し（ステップ３２４）、チャンクの取得時刻推定部２３２は、例えば、そのときのＡｃｋパケットのキャプチャ時刻（タイムスタンプから取得できる）をチャンク取得時刻としてメモリ等の記憶手段に保持する。
【００９６】
例えば、図１３に示した入力情報の例において、図１５に示すように、パケット８まで１４１６バイトの整数倍で増加するが、パケット９は、パケット８から７１２バイト（≠１４１６バイトの整数倍）だけしか増加していないから、パケット９の取得タイミングをチャンクのダウンロード完了タイミングと判定する。
【００９７】
（実施の形態のまとめ、効果等）
本実施の形態に係る技術によれば、例えば図９に示したとおり、動的にレート制御を実施するプログレッシブダウンロード型映像配信サービスにおいて、再生・停止のみならず、画質も含めた再生状態推定を高精度で実現可能である。
【００９８】
ここで、例えば非特許文献１〜３に記載された従来技術では、ＴＣＰヘッダ情報に基づき、配信される映像データのチャンクを識別する手段に言及していない。商用サービスにおいては、実装によりＨＴＴＰペイロードの解析によりチャンクの識別ならびにチャンク番号、画質の取得が可能である場合もある。しかし、当該手法は実装依存であり、ＨＴＴＰペイロード中にこれらの情報の記載が無い場合や、配信サービスがＨＴＴＰＳで実装されている場合には適用することができない。
【００９９】
一方、本実施の形態に係る技術では、ＴＣＰパケットのヘッダ情報に基づき、配信される映像データのチャンクの観測時刻、チャンク長等を識別できるので、ＨＴＴＰペイロード中に記載が無い場合や、ＨＴＴＰＳで実装されている場合でも、チャンク毎の画質を判別でき、画質変更箇所を検知することが可能である。
【０１００】
また、非特許文献１〜３に記載された従来技術では、画質変更を勘案していないため、画質変更発生時点以降のバッファ内チャンク数が現実と乖離する問題があるが、本実施の形態に係る技術では、これまでに説明したとおり、画質変更を勘案するため、動的レート制御を伴うプログレッシブダウンロード映像配信サービスを対象とする場合でも、正確にバッファ内チャンク数や再生状態を推定できる。つまり、本実施の形態では、画質変更前後の各画質の組合わせに依存して異なるアルゴリズムに基づきバッファ内チャンクを処理することが可能であり、バッファ内の画質切り替え処理を模擬することにより画質変更発生時にも高精度で再生状態推定を実現する技術を提供できる。
【０１０１】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１０２】
１００  映像再生状態推定装置、映像再生状態推定部
１  チャンク長密度推定部
２  画質変更検知部
２１  判定結果蓄積部
３  バッファ処理部
３１  再生状態蓄積部
２００  映像再生状態推定装置
２１０  パケットデータ取得部
２２０  記憶部
２３０  チャンク状態推定部
２３１  チャンクの時間長推定部
２３２  チャンクの取得時刻指定部
【図１】
0006053176.tif 000006
【図２】
0006053176.tif 000007
【図３】
0006053176.tif 000008
【図４】
0006053176.tif 000009
【図５】
0006053176.tif 000010
【図６】
0006053176.tif 000011
【図７】
0006053176.tif 000012
【図８】
0006053176.tif 000013
【図９】
0006053176.tif 000014
【図１０】
0006053176.tif 000015
【図１１】
0006053176.tif 000016
【図１２】
0006053176.tif 000017
【図１３】
0006053176.tif 000018
【図１４】
0006053176.tif 000019
【図１５】
0006053176.tif 000020