WO2013065804A1 - コンテンツ再生情報推定装置及び方法及びプログラム - Google Patents

コンテンツ再生情報推定装置及び方法及びプログラム Download PDF

Info

Publication number
WO2013065804A1
WO2013065804A1 PCT/JP2012/078392 JP2012078392W WO2013065804A1 WO 2013065804 A1 WO2013065804 A1 WO 2013065804A1 JP 2012078392 W JP2012078392 W JP 2012078392W WO 2013065804 A1 WO2013065804 A1 WO 2013065804A1
Authority
WO
WIPO (PCT)
Prior art keywords
reproduction
content
time
terminal
playback
Prior art date
Application number
PCT/JP2012/078392
Other languages
English (en)
French (fr)
Inventor
泰理 本多
山本 浩司
天真 中村
大介 池上
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2013541848A priority Critical patent/JP5780684B2/ja
Priority to US14/351,704 priority patent/US9781474B2/en
Priority to CN201280050761.7A priority patent/CN103875218B/zh
Priority to EP12846372.6A priority patent/EP2775673B1/en
Publication of WO2013065804A1 publication Critical patent/WO2013065804A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401Monitoring of the client buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4333Processing operations in response to a pause request

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

 配信サーバからネットワークを介して、コンテンツを端末に対して配信し、端末において該コンテンツを再生するシステムにおいて、前記配信サーバと前記端末間に設けられ、該コンテンツの再生に関する状態を推定するコンテンツ再生情報推定装置において、前記配信サーバから前記端末に配信されるパケットデータを取得して、記憶手段に格納する手段と、前記取得したパケットデータに基づいて、前記端末におけるバッファ内のデータ量を推定する手段と、前記推定されたデータ量と所定の閾値とを比較することにより、前記端末における前記コンテンツの各時刻における再生に関する状態を推定する手段とを備える。

Description

コンテンツ再生情報推定装置及び方法及びプログラム
 本発明は、コンテンツ再生情報推定装置及び方法及びプログラムに係り、特に、ネットワークを介してコンテンツデータを配信するシステムにおいて、映像等のプログレッシブダウンロード型のコンテンツの再生品質の推定を行うためのコンテンツ再生情報推定装置及び方法及びプログラムに関する。
 近年通信網の広帯域化が進んでおり、より多くのトラヒックがインターネットを介して流通するようになった。特に大きなファイルサイズを持つコンテンツをダウンロードしながらデータ処理を並行して行う、プログレッシブダウンロード型のコンテンツ配信システムが普及している。このようなコンテンツ配信形態では、ネットワークを介することによる遅延変動やパケットロス、再送等によりデータが一定速度で端末に到着せず、データの到着には送信タイミングに対して揺らぎが発生する。そのため、端末側でそのゆらぎを吸収するために、再生バッファを用意し、ネットワークの影響を上位アプリケーションに対して隠ぺいする仕組みが用いられることが多い。
 このようなコンテンツ配信形態では、処理の開始までに一定量のバッファリング(初期バッファ量)を要することが特徴であるが、そのバッファ量を大きくすることでネットワークによる影響を軽減することができる一方、データ処理開始までの時間が長くなり、レスポンスが悪くなる。そのため、様々な状況を鑑みて適切な大きさの初期バッファ量を設定する必要がある。例えば、パケットの転送遅延時間をもとに初期バッファ量を動的に変更させる手法がある(例えば、非特許文献1参照)。
 一方、一時的にネットワークのスループットがコンテンツデータの処理速度よりも低くなる場合には、再生バッファが一定量(再生停止閾値)を下回り、再生が停止されることがある。この再生停止は、当該コンテンツのユーザ体感品質に大きな影響を与えるが、従来技術では対応できないため、コンテンツの再生停止状態を推定し、把握する技術が必要とされる。
 また、コンテンツの配信方法として、単一のコンテンツであっても、複数の単位に分割して配信を行う形態も多い。これらの配信方式では、分割された各単位をチャンクと呼び、チャンク単位で再生バッファに格納される。すなわち、当該再生バッファに対して、チャンクの個数または蓄積されたチャンクの再生時間長等でバッファの管理が行われる。
Kouhei Fujimoto, Shingo Ata, Masayuki Murata, "Statistical Analysis of Packet delays in the Internet and Its Application to Playout Control for Streaming Applications," IEICE TRANSE. ON COMMUNICATION, VOL. E00-B, NO. 6 JUNE 2001
 再生停止状態の推定を行う場合、端末の内部で行う場合と、外部で行う場合の2つのパターンが考えられる。
 端末の中で行う場合には、実際に端末の内部でプログラムを動作させ、直接的なデータを取得し用いるため、精度を高くすることができるが、アプリケーションに合わせた作り込みや、クライアントプログラムの改変等が必要になることが想定される。この方法では対応アプリケーションを増やすことは難しく汎用性に欠ける。
 一方、端末の外部から推定を行う場合、端末へ転送されるパケットデータから推定を行うため、任意のアプリケーションに適用することができるため、汎用性は高い。その一方で、クライアントプログラム内での処理を模擬した上で再生停止状態の推定を行う必要がある。特定のアプリケーションに合わせて推定精度を高める方法は考えられるが、外部からの推定を行う利点である汎用性が失われるという欠点がある。そのため,汎用性を保ったまま再生状態の精度を高くすることが課題となる。
 また、キャプチャデータを基に再生停止と推定された場合において、再生停止の発生要因がネットワーク起因か、利用者の行動起因かを区別することができず、品質劣化要因の見極めが難しいという問題があり、例えば、ネットワークに問題がないにも関わらずネットワーク起因の品質劣化であると誤判定を行う可能性があった。このため、再生停止の推定にあたり、利用者が能動的に再生の一時停止を操作した状態か、ネットワークやサーバ等の機能低下等による自然な停止か否かの再生停止要因の識別を可能とすることが課題となる。
 本発明は、上記の点に鑑みなされたもので、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するシステムにおいて、コンテンツ配信システムの配信側(配信サーバ)、受信側(再生端末)に改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うことで、当該システムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うコンテンツ再生情報推定装置及び方法及びプログラムを提供することを目的とする。
 また、本発明は、ネットワークを介して端末が受信するチャンク単位のコンテンツデータの再生停止状態の推定にあたり、再生停止要因を識別し、再生停止状態の推定に反映することが可能なコンテンツの再生情報推定装置及び方法及びプログラムを提供することを目的とする。
 本発明の一実施形態によれば、配信サーバからネットワークを介して、コンテンツを端末に対して配信し、端末において該コンテンツを再生するシステムにおいて、前記配信サーバと前記端末間に設けられ、該コンテンツの再生に関する状態を推定するコンテンツ再生情報推定装置であって、
 前記配信サーバから前記端末に配信されるパケットデータを取得して、記憶手段に格納する手段と、
 前記取得したパケットデータに基づいて、前記端末におけるバッファ内のデータ量を推定する手段と、
 前記推定されたデータ量と所定の閾値とを比較することにより、前記端末における前記コンテンツの各時刻における再生に関する状態を推定する手段とを備えることを特徴とするコンテンツ再生情報推定装置が提供される。
 また、本発明の一実施形態によれば、ネットワークを介してコンテンツデータ配信を行う配信サーバと、前記配信サーバから受信したコンテンツデータを蓄積しながら再生する再生端末からなり、該再生端末が、該コンテンツデータを再生バッファに蓄積し、該再生バッファに初期バッファ量のコンテンツデータが蓄積されると再生を開始し、再生中は該再生バッファから再生に必要なデータを読み出し、該再生バッファに蓄積されたバッファ量が再生停止閾値を下回ると再生が停止し、該再生バッファに蓄積されたバッファ量が再生開始閾値を上回ると再生が開始する機能を有するシステムにおいて、端末におけるコンテンツデータの再生停止状態の推定を行うコンテンツ再生情報推定装置であって、
 前記ネットワークを介して送受信されるパケット情報を取得するパケット情報取得手段と、
 前記パケット情報の時系列情報に基づいて、前記再生端末にて各時刻に受信したコンテンツデータ量の時系列情報を推定するコンテンツ受信量推定手段と、
 前記コンテンツ受信量推定手段で推定された前記コンテンツデータ量を用いて、前記再生端末にて再生開始までに要した時間を推定する再生開始時間推定手段と、
 前記コンテンツデータ量を用いて、前記再生端末の再生アプリケーションが再生開始後の各時間に消費するデータ量から前記再生端末にて各時刻における状態が再生状態または停止状態のいずれにあるかを推定する再生状態推定手段と、
 前記再生状態推定手段において停止状態と判断された場合の再生が停止された時間およびその長さを推定する再生停止時間推定手段と、を有することを特徴とするコンテンツ再生情報推定装置が提供される。
 また、本発明の一実施形態によれば、配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定装置であって、
 前記配信サーバと前記端末間に設けられ、
 前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得手段と、
 前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定手段と、
 前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定手段と、
 予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、
 前記記憶手段の前記パケットデータと前記コンテンツリストを参照し、前記チャンク時間長推定手段で得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定手段で得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定手段と、を有することを特徴とするコンテンツ再生情報推定装置が提供される
 本発明の一実施形態によれば、コンテンツ配信システムの配信サーバと再生端末間の経路上においてパケットデータを取得し、その情報をもとに再生状態の推定を行うことで、配信システムへの改変を伴わずに、再生情報の取得を行うことができる。
 これにより、コンテンツ配信システムの外部から取得することの困難であった再生情報の推定を行うことが可能となる。また、配信サーバや端末への改変を行わないため、配信経路上の任意地点に本システムを設置することで、様々なコンテンツ配信システムに対する再生情報の推定を行うことが可能となる。特に、ストリーミングデータの配信においては、再生停止時間の大小よりも、そもそも再生停止が発生しているかどうかが再生品質に与える影響が大きいため、本発明に係る技術による再生情報の推定により、再生品質の推定に資する情報を得ることが可能になる。また、再生停止状態の推定において、停止状態と判定された場合に、その状態がユーザ操作によるものか否かを切り分けることが可能となる。
実施の形態1のシステム構成図である。 実施の形態1-1における処理のフローチャートである。 実施の形態1-1におけるコンテンツ受信量推定部の演算結果例である。 実施の形態1-1における再生アプリケーションが再生開始後の各時間に消費するデータ量である。 実施の形態1-1における再生状態に関する情報の推定結果例である。 実施の形態1-2におけるシステム構成図である。 実施の形態1-2における処理のフローチャートである。 実施の形態1-3におけるシステム構成図である。 実施の形態1-3における処理のフローチャートである。 実施の形態1-4におけるシステム構成図である。 実施の形態1-4における処理のフローチャートである。 実施の形態2におけるコンテンツ再生情報推定装置の構成図である。 実施の形態2-1における動作の概要を示すフローチャートである。 実施の形態2-1における停止推定手順のフローチャートである。 実施の形態2における再生状態推定部の具体的な動作を説明するための図である。 実施の形態2における再生状態推定部の具体的な動作を説明するための図である。 実施の形態2-2における停止推定手順のフローチャートである。 実施の形態2-3における動作の概要を示す図である。
 以下図面と共に、本発明の実施の形態を説明する。本実施の形態は、プログレッシブダウンロード型の映像配信サービスを対象としている。プログレッシブダウンロード型の映像配信サービスには、逐次型とチャンク型があり、以下、逐次型における実施の形態を実施の形態1とし、チャンク型における実施の形態を実施の形態2として説明する。また、実施の形態1は実施の形態1-1~実施の形態1-5を含み、実施の形態2は、実施の形態2-1~実施の形態2-4を含む。
 なお、本実施の形態では、プログレッシブダウンロード型の映像配信サービスを対象としているが、本発明は、プログレッシブダウンロード型の映像配信サービスに限定されるわけではなく、様々なコンテンツ配信サービスに適用できる。
 <実施の形態1>
 以下図面と共に、本発明の実施の形態1を説明する。
 本実施の形態1は、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するコンテンツ配信システムにおいて、配信側、受信側のいずれのプログラムにも改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うものである。
 図1は、実施の形態1におけるシステム構成を示す。
 同図に示すシステムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うコンテンツ再生情報推定装置100、再生端末200、コンテンツ格納装置300と、を有する。
 コンテンツ再生情報推定装置100は、パケット情報取得部110、コンテンツ受信量推定部120、再生開始時間推定部130、再生状態推定部140、再生停止時間推定部150を有する。
 再生端末200は、受信したコンテンツをバッファリングするための再生バッファ210を有する。
 コンテンツ格納装置300は、コンテンツをネットワークに送出するコンテンツ送出部310、送出するコンテンツを格納するコンテンツ格納部320を有する。
 パケット情報取得部110は、ネットワークを介して送受信されるパケットのキャプチャ情報(パケット情報)を取得する。
 コンテンツ受信量推定部120は、取得したキャプチャ情報から端末上の再生アプリケーションに渡されるデータ量の時系列情報の推定を行う。当該コンテンツ受信量推定部120は、再生端末200上の論理的に区切られた個所に実装することも可能である。また、事業者ネットワーク等の通信経路上の任意の位置に実装することも可能である。
 再生開始時間推定部130は、コンテンツ受信量推定部120で推定されたデータ量の時系列情報から再生開始時間を推定する。
 再生状態推定部140は、再生開始時間推定部130によって推定された再生端末200上の再生アプリケーションが再生開始後の各時間に消費するデータ量と、コンテンツ受信量推定部120によって推定された再生アプリケーションに渡されるデータ量の時系列情報とから、再生開始に要する時間や各時間における再生・停止状態の推定を行い、再生状態の推定を行う。
 再生提示時間推定部150は、再生状態推定部140において、再生が停止された状態であると判定された場合に、再生が停止された時刻及び停止された時間を推定する。
 以下、上記の構成における具体的な処理を説明する。
 [実施の形態1-1]
 以下、図1に示すシステムにおける再生停止時間推定処理について説明する。
 本実施の形態では、コンテンツ格納装置300を、複数のコンテンツデータを格納し、ネットワークを介してプログレッシブダウンロード型コンテンツデータを配信する手段を有するコンテンツデータ配信サーバ(以下、配信サーバと記す)として説明する。
 再生端末200は、配信サーバ300から受信したコンテンツを再生バッファ210に蓄積しながら再生する手段を有する。
 これらのコンテンツ再生情報推定装置100、配信サーバ300、再生端末200からなるシステムにおいて、配信経路上でキャプチャしたパケットの分析を行い、再生端末200の再生停止状態の推定を行うコンテンツ再生情報推定技術を以下に示す。
 図2は、実施の形態1-1における処理のフローチャートである。
 ステップ101) コンテンツデータの配信サーバ300と再生端末200の間に設置されたコンテンツ再生情報推定装置100において、パケット情報取得部110は、配信サーバ300と再生端末200間で交換されるパケット情報(パケットデータ)の一部またはすべての情報を取得する。このパケット情報取得部110は、一般的なsniffer装置、プログラム等を用いることが可能である。また、パケット情報取得部100を本発明に係るコンテンツ再生情報推定装置の外部に設置して、キャプチャされたパケット情報をコンテンツ受信量推定部120への入力としてもよい。
 ステップ102) コンテンツ受信量推定部120は、パケット情報取得部110で取得したパケット情報の一部または全てから、再生端末200上の再生アプリケーションに渡されるデータ量の時系列情報の推定を行い、再生開始時間推定部130に出力する。ここで、データ量の時系列情報は、例えば、RTPを用いた配信を行っている場合には、RTP(Real-time Transport Protocol)のシーケンス番号やタイムスタンプ情報を用いて受信バイト量の推定を行うことで取得できる。また、TCP(Transmission Control Protocol)を用いた場合でも、再生端末200におけるTCPプロトコルの挙動を模擬し受信バイト量の推定を行うことができる。
 パケット情報取得部110で受信したパケット情報を用いてコンテンツ受信量推定部120により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、開始される前である場合にはステップ103の処理に移行する。
 コンテンツ受信量推定部120における受信量の推定結果の一例を図3に示す。
 ステップ103) 再生開始時間推定部130では、コンテンツ受信量推定部120で推定されたデータ量の時系列情報から、再生開始に要する時間を推定する。例えば、再生開始に要する時間は、コンテンツが初めて再生を開始するバッファ量の閾値までデータを受信するのに要した時間とする。当該処理後、ステップ101の処理に戻る。
 ステップ104) パケット情報取得部110で受信したパケット情報を用いてコンテンツ受信量推定部120により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、再生が開始された後であり、かつ、コンテンツデータのサイズがパケットデータ中に記載されており、再生が終了していないと判断された場合、または、フローが切断されていないと判断された場合には、再生状態推定部140は、再生端末200上の再生アプリケーションが再生開始後の各時間に消費するデータ量から、再生端末200の通信開始後の任意の時刻において、再生が継続されているかどうかを判定する。例えば、以下の手順で判定を行う。
 再生アプリケーションにおけるバッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値をThp,コンテンツの再生を停止するバッファ量の閾値をThsとする。このとき、コンテンツ受信量推定部120で得られた受信量の時系列データおよび再生アプリケーションの再生時間後の各時間に消費するデータ量を入力とし、バッファ量の増減を行う。すなわち再生上にある場合、ある時刻において受信量がΔB増えていた場合には、バッファ量をΔB増分し、再生アプリケーションで消費されるデータ量がΔC増えていた場合には、バッファ量をΔC減少させる。これらの演算の結果、バッファ量の残量がThsを下回った場合には「再生状態」から「停止状態」に遷移させる。
 ここで、再生状態推定部140は、再生アプリケーションが再生開始後の各時間に消費するデータ量として、配信サーバ300と再生端末200間で交換されるパケット情報をもとに疑似的にデコードを行い、各再生時刻における必要データ量を求めてもよいし、予め定めた固定のビットレートで再生アプリケーションがデータを消費するとして算出してもよいが、これらに限るものではない。例えば、ビットレートが800kbps固定とした場合には、再生開始1秒後には、累積で100KBのデータ量を消費し、再生開始2秒後には累積で200KBのデータ量を消費すると考えられる。このように、再生端末200上の再生アプリケーションが再生開始後の各時間に消費するデータ量を時系列で与える。
 再生アプリケーションが再生開始後の各時間に消費するデータ量の一例を図4に示す。
 ステップ105) パケット情報取得部110で受信したパケット情報を用いてコンテンツ受信量推定部120により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、再生が開始された後であり、かつ、コンテンツデータのサイズがパケットデータ中に記載されており、再生が終了していると判断された場合、または、フローが切断されている判断された場合に、再生状態推定部140による推定結果が「停止状態」と推定された場合には、再生停止時間推定部150は、再生が停止された時刻や時間などの再生状態に関する情報の推定を行う。
 停止状態においてもバッファ量の増減を同様に行うが、再生端末200でのコンテンツの再生は停止された状態にあるため、アプリケーションが消費するデータ量は0となり、受信量の増分が加わるのみとなる。ことのきバッファ量の残量がThpを上回った場合に、コンテンツの再生が開始されるものと判定を行う。
 再生停止時間推定部150では、再生状態推定部140から取得した再生状態遷移情報から、再生が停止された時間およびその長さの推定を行う。なお、ここで、再生状態推定部140は、再生状態遷移情報として再生状態が遷移した時刻を内部のメモリ(図示せず)に記録しておき、再生提示時間推定部150が取得するものとする。
 出力される推定結果の一例を図5に示す。なお、当該推定結果を加工することで、総停止時間や停止回数を出力することも可能である。
 [実施の形態1-2]
 図6は、実施の形態1-2におけるシステム構成を示す。同図において、図1の構成と同一構成部分には同一符号を付し、その説明を省略する。
 図6に示すコンテンツ再生情報推定装置400は、図1のコンテンツ再生情報推定装置100の構成にバッファパラメータ推定部410を付加した構成である。
 図7は、本発明の第2の実施の形態における処理のフローチャートであり、第1の実施の形態の図2のフローと同一の処理については同一ステップ番号を付す。
 ステップ101) コンテンツ再生情報推定装置400のパケット情報取得部110において、配信サーバ300と再生端末200間で交換されるパケット情報の一部またはすべての情報を取得する。
 ステップ201) バッファパラメータ推定部410では、パケット情報取得部110で取得したネットワークを介して送受信されるパケット情報からバッファパラメータを推定する。バッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値やコンテンツの再生を停止するバッファ量の閾値、映像の符号化レートなどが該当する。推定に当たっては、予め定められたパケット中のデータのパターンマッチングによって行う。例えば、コンテンツの再生を開始するバッファ量の閾値として、HTTP GETメッセージで、"bc"というパラメータで送受されるとした場合には、"bc="に引き続く数字列を当該バッファパラメータとする。
 ステップ102) 次に、コンテンツ受信量推定部120において、パケット情報取得部110から取得したパケット情報の一部またはすべてから、再生端末200上の再生アプリケーションに渡されるデータ量の時系列情報を推定し、再生開始時間推定部130に出力する。
 ステップ103) 再生開始時間推定部130では、コンテンツ受信量推定部120で推定されたデータ量の時系列情報から、再生開始に要する時間を推定する。例えば、再生開始に要する時間は、バッファパラメータ推定部130で推定されたバッファパラメータ(コンテンツが再生を開始するバッファ量の閾値)までデータを受信するのに要した時間とする。
 ステップ104) また、再生状態推定部140では、再生端末200上の再生アプリケーションが再生開始後の各時間に消費するデータ量から、通信開始後の任意の時刻において、再生が継続されているかどうかを判定する。例えば、以下の手順で判定を行う。
 バッファパラメータ推定部410で取得したバッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値をthp、コンテンツの再生を停止するバッファ量の閾値をthsとする。このとき、コンテンツ受信量推定部120で得られた受信量の時系列データ及び再生アプリケーションの再生時間後の各時間に消費するデータ量を入力とし、バッファ量の増減を行う。すなわち再生上にある場合、ある時刻において受信量がΔB増えていた場合には、バッファ量をΔB増分し、再生アプリケーションで消費されるデータ量がΔC増えていた場合には、バッファ量をΔC減少させる。これらの演算の結果、バッファ量の残量がthsを下回った場合には、「再生状態」から「停止状態」に遷移させる。
 なお、再生アプリケーションが再生開始後の各時間に消費するデータ量の求め方は前述の実施の形態1-1と同様である。
 ステップ105) 再生状態推定部140で推定された再生状態が「停止状態」の場合には、再生停止時間推定部150において、再生が停止された時刻や時間などの再生状態に関する情報の推定を行う。「停止状態」においてもバッファ量の増減を同様に行うが、コンテンツは停止された状態にあるため、アプリケーションが消費するデータ量は0となり、受信量の増分が加わるのみとなる。ことのきバッファ量の残量がThpを上回った場合に、コンテンツの再生が開始されるものと判定を行う。
 再生停止時間推定部150では、前記再生状態推定部140から、再生が停止された時刻及び停止されていた時間の推定を行う。
 [実施の形態1-3]
 図8は、実施の形態1-3におけるシステム構成を示す。
 同図において、図1、図6と同一構成部分には同一符号を付す。
 また、図9は、実施の形態1-3における処理のフローチャートであり、図2、図7と同様の処理については説明を省略する。
 本実施の形態では、第1、第2の実施の形態において、ネットワークを介して送受信されるパケット情報から、再生端末200にて受信したコンテンツデータの各再生時刻において再生バッファ210から読み出されるデータ量を推定する再生レート推定部510を有し、当該再生レート推定部510の推定結果を再生開始時間推定部130に入力することを特徴とする。
 再生レート推定部510では、例えば、パケット情報取得部110で取得したパケット情報から配信サーバ300-再生端末200間で送受される情報を再構成し、再生端末200で再生されるコンテンツを抽出し、符号化された映像・音声データから、各再生時刻におけるデコード量を推定し、それを再生開始後の各時間に消費するデータ量として、再生開始時間推定部130に入力する(ステップ301)。パケットの情報からコンテンツの再生情報を推定することで前記端末上のアプリケーションが各時間に消費するデータ量をより正確に推定することができる。
 なお、再生レート推定部510以外の処理は前述の実施の形態と同様であるので、その説明を省略する。
 [実施の形態1-4]
 図10は、実施の形態1-4におけるシステム構成を示す。同図において、前述の実施の形態1-1~1-3における図1、図6、図8と同一構成部分には同一符号を付す。
 図11は、実施の形態1-4における処理のフローチャートである。
 本実施の形態のコンテンツ再生情報推定装置600では、実施の形態1-1、1-2において、ネットワークを介して送受信されるパケット情報から、再生端末200にて受信したコンテンツデータの総量およびコンテンツの再生時間長を推定するコンテンツ情報推定部610を有し、当該コンテンツ情報推定部610の推定結果を、再生状態推定部140に入力する。
 コンテンツ情報推定部610では、例えば、パケット情報取得部110で取得したHTTP GETメッセージの送受中に含まれるContent-Lengthヘッダや、TCPフローの生起および終了時のシーケンス番号の差分などの情報から、再生端末200にて受信したコンテンツデータの総量を推定する。また、コンテンツの再生時間長の推定にあたっては、予め定められたパケット中のデータのパターンマッチングによって行う。例えば、HTTP GETメッセージで、"len"というパラメータで送受されるとした場合には、"len="に引き続く数字列を当該バッファパラメータとして推定する(ステップ401)。
 推測されたコンテンツデータの総量をB,コンテンツの時間長をlenとおくと,当該コンテンツの平均ビットレートはB/lenとして考えることができるため、再生端末300上のアプリケーションが再生開始後の各時間に消費するデータ量をこの平均ビットレートから線形に算出し、再生状態推定部140への入力とする。
 その他の構成要素の処理は、前述の実施の形態と同様であるので、その説明を省略する。
 [実施の形態1-5]
 本実施の形態におけるシステム構成は、実施の形態1-4と同様であるが、本実施の形態では、コンテンツ情報推定部610において、予め定められたコンテンツ毎の再生レート固定値と再生端末200にて受信したコンテンツデータから、各再生時刻において再生バッファから読み出されるデータ量を推定し、推定結果を再生状態推定部140に入力する。このとき、再生端末200で受信したコンテンツデータは、パケット情報取得部110を介してコンテンツ情報推定部610に入力される。
 本実施の形態におけるコンテンツ情報推定部610では、例えば配信システムにおいて「高画質」「低画質」等の予め定められたコンテンツの画質情報等に基づき、再生レートを離散値として用意する。また、パケット情報から交換される情報からコンテンツ画質情報を推定し、該当する再生レートを当該コンテンツデータの平均ビットレートとする。この平均ビットレートを用いて,端末上のアプリケーションが再生開始後の各時間に消費するデータ量を線形に算出し、再生状態推定部への入力とする。
 その他の処理は、前述の実施の形態1-4と同様であるのでその説明を省略する。
 なお、上記の実施の形態1における図1、図6、図8、図10の各コンテンツ再生情報推定装置の構成要素の動作をプログラムとして構築し、コンテンツ再生情報推定装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
 すなわち、実施の形態1における各コンテンツ再生情報推定装置は、コンピュータに、本実施の形態1で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、コンテンツ再生情報推定装置の各部が有する機能は、当該コンテンツ再生情報推定装置を構成するコンピュータに内蔵されるCPUやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体(可搬メモリ等)に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
 <実施の形態2>
 次に、図面と共に本発明の実施の形態2を説明する。
 本実施の形態2は、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するシステムにおいて、当該システムに改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うことで、当該システムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うものである。
 図12は、実施の形態2におけるコンテンツ再生情報推定装置の構成を示す。
 同図に示すコンテンツ再生情報推定装置700は、チャンク単位の配信を行う配信サーバ10と端末20に接続されており、パケットデータ取得部710、記憶部720、再生状態推定部730、チャンク状態推定部740から構成される。端末20は、少なくとも再生バッファと再生アプリケーションを有する。
 本実施の形態では、配信サーバ10は、端末20に対して、一つのコンテンツを複数のチャンク単位に分割して配信する。端末20は、再生バッファを有し、当該再生バッファに、所定のチャンク数が蓄積されると、再生を開始し、再生中は、当該再生バッファから再生に必要なデータを読み出し、再生バッファに蓄積されたチャンク数が再生停止閾値を下回ると再生が停止し、再生開始閾値を上回ると再生が開始する機能を有する。
 パケットデータ取得部710は、配信サーバ10から端末20に対してチャンク単位で配信されるパケットの情報を取得し、記憶部720に格納する。取得する情報として、パケットの情報(パケットデータ)、チャンク単位のパケットキャプチャ情報、コンテンツリスト等である。チャンク単位のパケットキャプチャ情報は、パケット単位のキャプチャデータをチャンク単位に分割して取得する。
 チャンク状態推定部740は、チャンクの時間長推定部741とチャンクの取得時刻推定部742を有する。
 チャンクの時間長推定部741は、記憶部720からチャンクの情報、またはあらかじめ既知のコンテンツ規則等を読み出して、各チャンクの再生時間長のリストを作成する。再生時間長のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。
 チャンクの取得時刻推定部742は、記憶部720からパケットキャプチャ情報を読み出して、各チャンクの送受信が完了した時刻を推定し、各チャンクの取得時刻のリストを作成する。取得時刻のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。
 再生状態推定部730は、チャンクの時間長推定部741で作成された各チャンクの再生時間長のリストおよびチャンクの取得時刻推定部742で作成された各チャンクの取得時刻のリストから、各時刻における再生バッファ中の残個数について推定し、現在コンテンツが再生状態にあるのか、または停止時状態にあるのか、また、再生開始に要する時間等の再生情報の推定を行う。
 例えば、端末20において、1つでもチャンクの受信を完了すると再生が開始され、チャンクの個数が0になると再生が停止するシステムを想定する。このとき、コンテンツ再生開始要求の直後に、パケットデータ取得部710において、3つのチャンクデータを受信しており、3つのチャンクデータで30秒のコンテンツ時間長を有していると仮定すると、再生開始直後に再生が開始され、再生状態が30秒継続する。また、この次のチャンクデータが到着しない間は、再生の停止状態が継続し、次のチャンクデータを受信完了した時点で再生が再開される。以降は同様に、受信完了したチャンクデータの残個数により、再生状態を推定する。
 [実施の形態2-1]
 以下では、コンテンツ再生情報推定装置として前述の図12に基づいて説明する。
 コンテンツデータの配信サーバ10と端末20の間に設置されたコンテンツ再生情報推定装置700は、パケットデータ取得部710において、配信サーバ10と端末20間でチャンク単位に交換されるパケットデータの一部またはすべての情報を取得し、記憶部720に格納する。このパケットデータ取得部710は、一般的なパケットモニタ装置、プログラム等で代替可能である。また、キャプチャされたパケットデータを記憶部720に格納せずに、直接チャンクの時間長推定部741、またはチャンクの取得時間推定部742への入力としてもよい。本実施の形態では、記憶部720にパケットデータを格納し、チャンク状態推定部740において、パケットデータを読み出すものとして説明する。また、チャンクの時間長推定部741及びチャンクの取得時間推定部742は、メモリ(図示せず)を有し、チャンクの再生時間長のリストであるチャンク時間長リスト及びチャンクの取得時刻リストを格納するものとする。
 図13は、実施の形態2-1における動作の概要を示すフローチャートである。
 本実施の形態では、同図に示すように、パケットデータが入力される度にパケットデータ取得部710において、記憶部720に格納し(ステップ501)、チャンクの再生時間長推定部741が記憶部720からパケットデータを読み出して、チャンクの再生時間長を推定し、チャンク時間長リストを更新する(ステップ502)。また、チャンクの取得時刻推定部742が記憶部720からパケットデータを読み出して、チャンクの取得時刻を推定し、チャンクの取得時刻リストの更新を行い(ステップ503)、フロー受信が終了した時点で(ステップ504,Yes)、再生状態推定部730による処理を行う(ステップ505)。
 チャンクの時間長推定部741は、記憶部720に格納されたパケットデータ(チャンク番号と時間長)の一部またはすべてから、端末20上の再生アプリケーションに渡される各チャンクの再生時間長を推定し、チャンク時間長リストとしてメモリ(図示せず)に格納する。各チャンクの再生時間長は、事前に決められたフォーマット等でコンテンツリスト(ファイルリスト)を配信サーバ10と交換し、その中の時間長の記載から抽出してもよい。また、各チャンクの再生時間長は一定ではなく、コンテンツの識別子等から事前に取得したチャンクの再生時間長に該当する時間長としてもよい。また、各チャンクのエンコードされたデータをデコードし、対応するコーデックのタイムスタンプ等から時間長を推定してもよい。例えば、コンテンツリスト(ファイルリスト)として、HLS(HTTP Live Streaming)(R. Pantos, Ed., W. May, "HTTP Live Streaming," IETF Internet-Draft, Sept. 2011.参照)に準拠した形式であり、コンテンツリスト中に各チャンクファイルのURI(Unified Resource Indicator)および時間長が記載されているものを用いることができる。
 チャンクの取得時刻推定部742は、記憶部720に格納されているパケットデータの一部またはすべてから、端末20上の再生アプリケーションに渡される各チャンクの取得時刻をパケットデータから得られるチャンクの取得完了時刻から推定し、チャンクの取得時刻リストとしてメモリ(図示せず)に格納する。取得時刻は、各チャンクの取得が完了した時刻を指すが、取得完了時刻の取得が困難な場合には、取得開始時刻をその代替としてもよい。なお、ここで、取得開始時刻を用いると、微少なタイムラグがあるが、ネットワークの状態がある程度一定であると仮定すると、一定時間の相対的な差となるため、許容できる。なお、取得完了時刻と開始時刻の両者を用いて判定を行うプロセスにおいては、完了時刻を開始時刻で代替することはできない。
 再生状態推定部730は、チャンクの時間長推定部741で推定、作成された各チャンクの再生時間長及びチャンクの取得時刻推定部742で推定、作成された各チャンクの取得時刻をもとに、コンテンツの再生状態の推定を行う。
 例えば、以下の手順で推定を行う。
 まず、再生アプリケーションにおけるバッファパラメータとして、
 ・コンテンツの再生を開始する際のバッファ中のチャンク数の閾値th_p;
 ・再生を停止するチャンク数の閾値th_s;
 ・再生を再開する際のチャンク数の閾値th_r;
を予め設定する。このとき、任意の時刻において端末20のバッファに蓄積されているチャンク数の推定を、チャンク状態推定部740で推定された各チャンクの再生時間長(チャンクの再生時間長のリスト)及び各チャンクの取得時刻(各チャンクの取得時刻のリスト)をもとに行う。th_p個目のチャンクを取得した時刻をT_0として、推定された再生開始時刻とする。ここで、再生開始のチャンク数の閾値th_pを越えた時刻を再生開始時刻推定値とする。
 次に、再生中のチャンク番号を示す変数iを1に設定し、現在バッファに蓄積されているチャンク数をnとしてth_pを設定する。また、再生状態の推定を行う対象時刻TにT_0を設定する。ここで、コンテンツの最初のチャンクのチャンク番号iを1とし、以降、チャンクの再生順に1加算した値(i=i+1)をチャンク番号iに設定し、チャンクの再生時間長のリストの各i番目のチャンクの再生時間長をlen_iとおき、チャンクの取得時刻リストの各チャンクの取得時刻を、コンテンツの最初のチャンクデータの取得開始の時刻を0とした相対値でt_iとおく。以下、本実施の形態では、特別の記述がない限り、時刻はすべて再生開始からの相対値として考える。
 i番目のチャンク再生後に停止が発生するかを以下の手順で確認する。
 図14は、実施の形態2-1における停止推定手順のフローチャートである。
 ステップ600) カウンタn=0,CNT=0とする。
 ステップ601) 各チャンクの取得時刻を記録したリストにおいて、取得時刻が、前回バッファに蓄積されているチャンク数nを増加した時刻Tより大きく、T+len_i以下となる(T<t_i≦T+len_i)チャンクの個数(CNT)をカウントし、現在バッファに蓄積されているチャンク数nに加算する。
 ステップ602) 現在バッファに蓄積されているチャンク数nから1減少させる。
 ステップ603) 現在バッファに蓄積されているチャンク数nと再生を停止するチャンク数の閾値th_sを比較し、nが大きい場合には、再生状態にあるとし、nが等しいか、または小さい場合には、停止状態になったと推定する。
 ステップ604) また、各種変数に対し、Tをlen_i増加させ(T=T+len_i)、iを1増加させ(i=i+1)、更新する。
 ステップ605) コンテンツを構成するチャンクのうち、コンテンツリストに記載のファイル全てを処理していない、または、予め決められた個数のチャンクを処理していない場合は、未処理のチャンクがあると判定し、ステップ603で再生状態であると判断されている場合には、ステップ601に移行する。一方、未処理のチャンクがあり、ステップ603で停止状態であると判断されている場合は、ステップ606に移行する。すべてのチャンクを処理している場合には、ステップ610に移行する。なお、コンテンツリストには、少なくとも、コンテンツ識別子(ID)、当該コンテンツに含まれるチャンク毎のチャンク識別子(ID)が含まれているものとし、現在処理対象のチャンクが最終のチャンクでない場合は、未処理のチャンクがあるものと判断する。
 ステップ606) 未処理のチャンクがあり、停止状態の場合には、次のチャンクを取得した時刻までTを進め(Tの値を更新)、現在バッファに蓄積されているチャンク数nを1増加させる。
 ステップ607) 現在バッファに蓄積されているチャンク数nと再生を再開するチャンク数の閾値th_rを比較し、nがth_rより大きい場合には、ステップ608に移行し、nがth_rと等しいかまたはth_rより小さい場合には、ステップ609に移行する。
 ステップ608) 再生状態に遷移すると推定する。
 ステップ609) 引き続き停止状態にあると推定する。
 ステップ610) 以降を全て再生状態として、各時刻における再生状態の系列を出力する。
 上記のフローチャートの例を具体的な例を用いて示す。
 図15A、図15Bに、具体例を示す。図15Aは、前提条件を示し、図15Bは動作の遷移を示す。
 チャンク番号iがi=1のとき、1番目のチャンク再生後の判断から開始するものとする。なお、開始の時点で、nはth_pと等しく、5である。
 [前回チャンク数を増加した時刻t_5(絶対値)=10<取得時刻(絶対値)≦T+len_1=12]に該当するチャンク数をカウントし、t_6が該当するので、n=n+1=6とする(ステップ601)。現在バッファに格納されているチャンク数6から1を引く(n=6-1=5)(ステップ602)。これにより、n=5であるので、th_s=3より大きいため、再生状態と判定する(ステップ603、Yes)。T=T+len_1=12、i=2とする(ステップ604)。未処理のチャンクがあり、再生状態と判定されているので、ステップ601の処理に戻る(ステップ605)。
 2回目の処理として、[前回チャンク数を増加した時刻t_6(絶対値)=12<取得時刻(絶対値)≦T+len_2=14]に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ601)。n=5-1=4とし(ステップ602)、n=4であるため、th_s=3より大きいため、再生状態と判定する(ステップ603,Yes)。
 3回目の処理として、[前回のチャンク数を増加した時刻t_6(絶対値)=12<取得時刻(絶対値)≦T+len_3=16]に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ601)。n=4-1=3とし(ステップ602)、n=3であるため、th_s=3と等しいため、停止状態と判定する(ステップ603,No)。T=t+len_3=16,i=4とする(ステップ604)。ここで、未処理のチャンクがあるため、Tを次のチャンクの取得時間に更新する。この場合T=17となる。つまり、チャンク番号i=3は14~16秒の間に再生されたが16秒において停止状態となった。
 停止状態となったため、次のチャンクを取得し、T=t_7(絶対値)=17、n=n+1=3+1=4となる(ステップ606)。n=4であるため、再生を再開する際のチャンク数の閾値th_r(=4)と比較すると4≦4となり、等しいため停止状態と判定する(ステップ607)。
 次のチャンク取得時刻であるT=18に更新し、次のチャンクを取得し、T=t_8(絶対値)=18であるので、n=n+1=4+1=5とする(ステップ606)。n=5でありth_r(=4)と比較すると、nのほうが大きいので、再生状態とする(ステップ607)。
 次にステップ601の処理に移行し、[前回チャンク数を増加した時刻t_8(絶対値)=18<取得時刻(絶対値)≦T+len_4=18]に該当するチャンク数をカウントするが、t_9が該当しないケースであるのでチャンク数への加算を行わない(ステップ601)。n=5-1=4とし(ステップ602)、n=4であり、4(n)>3(th_s)となり、再生状態と判定する(ステップ603、Yes)。T=T+len_4=18,i=5とする(ステップ604)。未受信のチャンクがあり、再生状態であるので(ステップ605)、ステップ601の処理に移行する。
 ステップ601において、[前回チャンク数を増加した時刻t_8(絶対値)=18<取得時刻(絶対値)≦T+len_5=20]に該当するチャンク数をカウントし、n+2=7によりt_9,10が該当するケースであるので、n=7-1=6とする(ステップ601)。6(n)>3(th_s)となるため、再生状態と判定する(ステップ603,Yes)。T=T+len_5=20、i=6とする(ステップ604)。未受信のチャンクがあり、再生状態であるのでステップ601に移行する。
 上記のようにして導出された再生状態判定結果に基づいて、総停止時間や停止回数等の統計情報を求めることが可能となる。なお、統計情報を求めることは既存の技術を用いて実現可能であり、本発明の範囲外であるのでその説明は省略する。
 なお、各種の閾値は、再生状態や停止の回数等に応じて動的に変動する値でもよいものとする。
 また、チャンクの取得時刻指定部742において、パケットデータから時間長の取得が困難な場合には、チャンク取得の時間間隔から導出される値をチャンクの時間長としてもよい。
 [実施の形態2-2]
 上記の実施の形態2-1では、取得済みのチャンク数の遷移を推定することで再生状態の推定を行うことができるが、キャプチャデータを基に再生停止と推定された場合において、再生停止の発生原因がネットワークに起因するものか、利用者の行動に起因するものかを区別することを考慮していない。
 本実施の形態では、再生停止の原因がネットワークか利用者の行動のいずれであるかを推定するために以下の処理を行う。
 図16は、実施の形態2-2における停止推定手順のフローチャートである。
 ステップ701) カウンタnとCNTを初期化し、n=0、CNT=0とする。
 ステップ702) 各チャンクの取得時刻を記録したリストにおいて、取得時刻が、前回バッファに蓄積されているチャンク数nを増加した時刻Tより大きく、T+len_i以下となる(T<t_i≦T+len_i)チャンクの個数をカウントし、現在バッファに蓄積されているチャンク数nに加算する。
 ステップ703) ステップ702で加算対象としたチャンクに対して、取得開始時刻を時系列でソートした際に、i番目とi+1番目のチャンク番号が不連続となっている(チャンク番号の増加数が1でない)か、を判定し、連続している場合はステップ704に移行し、チャンク番号が不連続の場合は、ユーザ操作により蓄積されているチャンクの範囲外への早送り、巻き戻し等が発生したものと判定し、ステップ701に移行し、各カウンタをリセットする。また、このフローにおける判定を打ち切り、検出した非連続な番号(i+1番目)から推定を開始する。
 ステップ704) ステップ702で加算対象とした各チャンクに対して、チャンクの取得開始時刻及び取得完了時刻から、チャンクの取得が完了してから次のチャンクの取得を開始するまでの時間tを算出する。
 ステップ705) ステップ704で算出された時刻tが直前に再生していたチャンクの再生時間長len_(i-1)よりも一定程度(α)大きい場合は、ユーザ操作により再生が一時停止されたものと判定し、ステップ706に移行する。
 ここで、一定程度(α)とは、推定された各チャンクの再生時間と実際の再生時間の誤差を吸収するための値であり、チャンクの再生時間の長さであるチャンクの再生時間長そのものを用いてもよいし、1.1倍などの固定の値を用いる方法や、一定時間長を用いたり、ネットワーク遅延時間の分散を考慮した値を用いてもよい。当該一定程度の時間をどのように決定するかにより精度が変化する。精度を向上させるには、想定されるチャンクの再生時間長と実際の時間長との誤差(ずれ)を許容できるような幅を持って設定する必要がある。一方で、ユーザ操作として識別したい最低の時間長より小さい誤差である必要がある。そのため、αとして、1秒程度の固定的な時間長を用いることが望ましい。また、サービス毎に検証を行い、最適値を定めてもよい。
 ステップ706) ステップ705において再生が一時停止状態と判定された場合には、バッファに蓄積されているデータ量の減少は行わない。また、バッファの減少を行わない時間の起点は、最後に受信したチャンクの取得開始時刻rr_jにチャンク時間長を加えた値から、最後に受信したチャンクの取得完了時刻rs_jにチャンク時間長を加えた値までの任意の時点としてもよい。例えば、rr_j-rs_jがチャンク時間長より小さい場合には、バッファの減少を行わない時刻の起点を、
    rs_j+チャンク時間長/2
とし、大きい場合には、rr_iを採用する、などしてもよい。また、次に新たなチャンクの取得を開始された場合に、ステップ702に移行する。
 チャンクを用いた映像配信サービスでは、新たなチャンクの取得が再生状態と密接に関連する。特に、端末において再生前に蓄積可能なチャンク数や該当する再生時間長に上限がある場合、再生中のチャンクの再生が終了していない限り新たなチャンクの取得が行われないことが特徴である。そのため、チャンクのダウンロードが完了してから、次のチャンクのダウンロードが開始されるまでの時間に着目することで、当該チャンクの再生開始から再生終了までに要した時間が、当該チャンクの再生時間の長さにかかるチャンクの再生時間長よりも長い場合(ステップ705,Yes)には、ユーザ操作によって発生した一時停止と判定することが可能となる。
 また、ユーザ操作が関与しない場合には、コンテンツは予め定められた順番に再生される。そのため、チャンク番号は必ず連続になるため、チャンク番号が非連続となった場合(ステップ703,Yes)には、ユーザ操作が行われたものと判定できる。
 ステップ707) 現在バッファに蓄積されているチャンク数nから1減少させる。
 ステップ708) 現在バッファに蓄積されているチャンク数nと再生を停止するチャンク数の閾値th_sを比較し、nが大きい場合には、再生状態にあるとし、nがth_sと等しいか、または小さい場合には、停止状態になったと推定する。
 ステップ709) また、各種変数に対し、Tをlen_i増加させ(T=T+len_i)、iを1増加させ(i=i+1)、更新する。
 ステップ710) コンテンツを構成するチャンクのうち、コンテンツリストに記載のファイル全てを処理していない、または、予め決められた個数のチャンクを処理していない場合は、未処理のチャンクがあると判定し、ステップ708で再生状態であると判断されている場合には、ステップ702に移行する。一方、未処理のチャンクがあり、ステップ708で停止状態であると判断されている場合は、ステップ711に移行する。すべてのチャンクを処理している場合には、ステップ715に移行する。なお、コンテンツリストには、少なくとも、コンテンツ識別子(ID)、当該コンテンツに含まれるチャンク毎のチャンク識別子(ID)が含まれているものとし、現在処理対象のチャンクが最終のチャンクでない場合は、未処理のチャンクがあるものと判断する。
 ステップ711) 未処理のチャンクがあり、停止状態の場合には、次のチャンクを取得した時刻までTを進め(Tの値を更新)、現在バッファに蓄積されているチャンク数nを1増加させる。
 ステップ712) 現在バッファに蓄積されているチャンク数nと再生を再開するチャンク数の閾値th_rを比較し、nがth_rより大きい場合には、ステップ713に移行し、nがth_rと等しいかまたはth_rより小さい場合には、ステップ714に移行する。
 ステップ713) 再生状態に遷移すると推定する。
 ステップ714) 引き続き停止状態にあると推定する。
 ステップ715) 以降を全て再生状態として、各時刻における再生状態の系列を出力する。
 上記のフローチャートの例を具体的な例を、実施の形態2-1と同様に、前述の図15A、15Bを用いて示す。
 実施の形態2-1と同様に、チャンク番号iがi=1のとき、1番目のチャンク再生後の判断から開始するものとする。
 [前回チャンク数を増加した時刻t_5(絶対値)=10<取得時刻(絶対値)≦T+len_1=12]に該当するチャンク数をカウントし、t_6が該当するので、n+1=6とする(ステップ702)。現在バッファに格納されているチャンク数6から1を引く(n=6-1=5)(ステップ707)。これにより、n=5であるので、th_s=3より大きいため、再生状態と判定する(ステップ708、Yes)。T=T+len_1=12、i=2とする(ステップ709)。未処理のチャンクがあり、再生状態と判定されているので、ステップ702の処理に戻る(ステップ710)。
 2回目の処理として、[前回チャンク数を増加した時刻t_6(絶対値)=12<取得時刻(絶対値)≦T+len_2=14]に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ702)。n=5-1=4とし(ステップ707)、n=4であるため、th_s=3より大きいため、再生状態と判定する(ステップ708,Yes)。
 3回目の処理として、[前回のチャンク数を増加した時刻t_6(絶対値)=12<取得時刻(絶対値)≦T+len_3=16]に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ702)。n=4-1=3とし(ステップ707)、n=3であるため、th_s=3と等しいため、停止状態と判定する(ステップ708,No)。T=t+len_3=16,i=4とする(ステップ709)。ここで、未処理のチャンクがあるため、Tを次のチャンクの取得時間に更新する。この場合T=17となる。つまり、チャンク番号i=3は14~16秒の間に再生されたが16秒において停止状態となった。
 停止状態となったため、次のチャンクを取得し、T=t_7(絶対値)=17、n=n+1=3+1=4となる(ステップ711)。n=4であるため、再生を再開する際のチャンク数の閾値th_r(=4)と比較すると4≦4となり、等しいため停止状態と判定する(ステップ712)。
 次のチャンク取得時刻であるT=18に更新し、次のチャンクを取得し、T=t_8(絶対値)=18であるので、n=n+1=4+1=5とする(ステップ711)。n=5でありth_r(=4)と比較するとnのほうが大きいので、再生状態とする(ステップ712)。
 次にステップ702の処理に移行し、[前回チャンク数を増加した時刻t_8(絶対値)=18<取得時刻(絶対値)≦T+len_4=18]に該当するチャンク数をカウントするが、t_9が該当しないケースであるのでチャンク数に加算しない(ステップ702)。n=5-1=4とし(ステップ707)、n=4であり、4(n)>3(th_s)となり、再生状態と判定する(ステップ708、Yes)。T=T+len_4=18,i=5とする(ステップ709)。未受信のチャンクがあり、再生状態であるので(ステップ710)、ステップ702の処理に移行する。
 ステップ702において、[前回チャンク数を増加した時刻t_8(絶対値)=18<取得時刻(絶対値)≦T+len_5=20]に該当するチャンク数をカウントする。n+2=7によりt_9,10が該当するケースであるので、n=7-1=6とする(ステップ702)。6(n)>3(th_s)となるため、再生状態と判定する(ステップ708,Yes)。T=T+len_5=20、i=6とする(ステップ709)。未受信のチャンクがあり、再生状態であるのでステップ702に移行する。
 上記のようにして導出された再生状態判定結果に基づいて、総停止時間や停止回数等の統計情報を求めることが可能となる。なお、統計情報を求めることは既存の技術を用いて実現可能であり、本発明の範囲外であるのでその説明は省略する。
 なお、各種の閾値は、再生状態や停止の回数等に応じて動的に変動する値でもよいものとする。
 また、チャンクの取得時刻指定部742において、パケットデータから時間長の取得が困難な場合には、チャンク取得の時間間隔から導出される値をチャンクの再生時間長としてもよい。
 チャンクを用いた映像のサービスでは、再生に先駆けてチャンクのダウンロードを行い、一定数のチャンクを蓄積することで再生を開始する。また、ひとたび再生が開始されると、既に取得した未再生のチャンクが一定数あれば再生を継続するが、一定数を下回ると再生が停止する。例えば、取得済みの未再生のチャンクが0であり、次に再生すべきチャンクをダウンロード中の場合には、再生を継続することができないため、一時停止状態となる。
 従って、取得済みのチャンク数の推移を推定することで、再生状態の推定を行うことが可能となる。取得済みのチャンク数が変化するタイミングは、新たにチャンクを取得完了した場合及び再生中のチャンクの再生を完了した場合の2つに限定される。そのため、キャプチャデータから前者を、コンテンツのビットレート及び経過時間で後者を推定することで、取得済みで未再生のチャンク数の推定を行う。
 [実施の形態2-3]
 図17は、実施の形態2-3の動作のフローチャートである。
 実施の形態2-1、2-2は、事前にキャプチャデータから時間長リスト、取得時刻リストを作成するものであったが、本実施の形態では、キャプチャデータの入力の度に当該2つのリストの更新を順不同で行い、T+len_iの再生時間が経過した時点で、再生状態推定部730の処理を行い、新たに再生状態の推定を行う対象時刻Tを更新する。図17のフローチャートにおいて、「新たなチャンクを再生に使用」(ステップ804)とは、
 ・再生状態にあるときに、iをインクリメントして、再生バッファ中のチャンクを再生する;
 ・停止状態にあるときに、新たにチャンクのデータを取得;
の2つの意味を含む。
 [実施の形態2-4]
 実施の形態2-1、2-2のチャンクの時間長推定部741において、時間を直接出すのではなく、受信バイト量および再生レートからチャンクの再生時間長を推定する。なお、チャンクの受信バイト量は、パケット情報取得部710においてチャンク単位の情報を出力する際に容易に取得できる。また、再生レートは、予め定められた識別子(例えば、コンテンツリストやチャンクを示すURL中の画質サイズを表す文字列等)によって規定されたものでもよく、また、コンテンツリストに直接記載してあるものを用いてもよい。
 上記のように、本実施の形態2では、コンテンツ配信システムの配信サーバと再生端末間の経路上においてパケットデータを取得し、その情報をもとに再生情報の推定を行うことで、配信システムへの改変を伴わずに、再生情報の取得を行うことができる。
 なお、上記の図12のコンテンツ再生情報推定装置の各構成要素の動作をプログラムとして構築し、コンテンツ再生情報推定装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
 すなわち、図12のコンテンツ再生情報推定装置は、コンピュータに、本実施の形態2で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、コンテンツ再生情報推定装置の各部が有する機能は、当該コンテンツ再生情報推定装置を構成するコンピュータに内蔵されるCPUやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体(可搬メモリ等)に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
 なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
 本国際出願は2011年11月2日に出願した日本国特許出願2011-241173号、2012年2月15日に出願した日本国特許出願2012-31125号、及び2012年7月4日に出願した日本国特許出願2012-150926号に基づく優先権を主張するものであり、日本国特許出願2011-241173号、日本国特許出願2012-31125号、及び日本国特許出願2012-150926号の全内容を本国際出願に援用する。
100 コンテンツ再生情報推定装置
110 パケット情報取得部
120 コンテンツ受信量推定部
130 再生開始時間推定部
140 再生状態推定部
150 再生停止時間推定部
200 再生端末
210 再生バッファ
300 コンテンツ格納装置
310 コンテンツ送出部
320 コンテンツ格納部
400 コンテンツ再生情報推定装置
410 バッファパラメータ推定部
500 コンテンツ再生情報推定装置
510 再生レート推定部
600 コンテンツ再生情報推定装置
610 コンテンツ情報推定部
10 配信サーバ
20 端末
700 コンテンツ再生情報推定装置
710 パケットデータ取得部
720 記憶部
730 再生状態推定部
740 チャンク状態推定部
741 チャンクの時間長推定部
742 チャンクの取得時刻指定部
 

Claims (16)

  1.  配信サーバからネットワークを介して、コンテンツを端末に対して配信し、端末において該コンテンツを再生するシステムにおいて、前記配信サーバと前記端末間に設けられ、該コンテンツの再生に関する状態を推定するコンテンツ再生情報推定装置であって、
     前記配信サーバから前記端末に配信されるパケットデータを取得して、記憶手段に格納する手段と、
     前記取得したパケットデータに基づいて、前記端末におけるバッファ内のデータ量を推定する手段と、
     前記推定されたデータ量と所定の閾値とを比較することにより、前記端末における前記コンテンツの各時刻における再生に関する状態を推定する手段と
     を備えることを特徴とするコンテンツ再生情報推定装置。
  2.  ネットワークを介してコンテンツデータ配信を行う配信サーバと、前記配信サーバから受信したコンテンツデータを蓄積しながら再生する再生端末からなり、該再生端末が、該コンテンツデータを再生バッファに蓄積し、該再生バッファに初期バッファ量のコンテンツデータが蓄積されると再生を開始し、再生中は該再生バッファから再生に必要なデータを読み出し、該再生バッファに蓄積されたバッファ量が再生停止閾値を下回ると再生が停止し、該再生バッファに蓄積されたバッファ量が再生開始閾値を上回ると再生が開始する機能を有するシステムにおいて、端末におけるコンテンツデータの再生停止状態の推定を行うコンテンツ再生情報推定装置であって、
     前記ネットワークを介して送受信されるパケット情報を取得するパケット情報取得手段と、
     前記パケット情報の時系列情報に基づいて、前記再生端末にて各時刻に受信したコンテンツデータ量の時系列情報を推定するコンテンツ受信量推定手段と、
     前記コンテンツ受信量推定手段で推定された前記コンテンツデータ量を用いて、前記再生端末にて再生開始までに要した時間を推定する再生開始時間推定手段と、
     前記コンテンツデータ量を用いて、前記再生端末の再生アプリケーションが再生開始後の各時間に消費するデータ量から前記再生端末にて各時刻における状態が再生状態または停止状態のいずれにあるかを推定する再生状態推定手段と、
     前記再生状態推定手段において停止状態と判断された場合の再生が停止された時間およびその長さを推定する再生停止時間推定手段と、
     を有することを特徴とするコンテンツ再生情報推定装置。
  3.  前記パケット情報からバッファパラメータを推定するバッファパラメータ推定手段を更に有し、
     前記再生開始時間推定手段は、
     前記コンテンツ受信量推定手段で推定された前記コンテンツデータ量の時系列情報及び前記バッファパラメータ推定手段において推定された前記バッファパラメータから、前記再生端末上の再生アプリケーションが再生開始後の各時間に消費するデータ量の推定を行い、再生開始に要する時間を推定する手段を含む
     請求項2記載のコンテンツ再生情報推定装置。
  4.  前記パケット情報から、前記再生端末にて受信したコンテンツデータの各再生時刻において前記再生バッファから読み出されるデータ量を推定する再生レート推定手段を更に有し、
     前記再生開始時間推定手段は、
     前記再生レート推定手段によって推定された前記データ量を用いて、再生開始に要する時間を推定する手段を含む
     請求項2または3に記載のコンテンツ再生情報推定装置。
  5.  前記パケット情報の前記再生端末にて受信したコンテンツデータの総量およびコンテンツの再生時間長から各再生時刻において前記再生バッファから読み出されるデータ量を推定する第1のコンテンツ情報推定手段を更に有し、
     前記再生開始時間推定手段は、
     前記第1のコンテンツ情報推定手段によって推定された前記データ量を用いて、再生開始に要する時間を推定する手段を含む
     請求項2または3に記載のコンテンツ再生情報推定装置。
  6.  予め定められたコンテンツ毎の再生レート固定値と前記再生端末にて受信したコンテンツデータから、各再生時刻において再生バッファから読みだされるデータ量を推定する第2のコンテンツ情報推定手段を更に有し、
     前記再生開始時間推定手段は、
     前記第2のコンテンツ情報推定手段によって推定された前記データ量を用いて、再生開始に要する時間を推定する手段を含む
     請求項2または3記載のコンテンツ再生情報推定装置。
  7.  配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定装置であって、
     前記配信サーバと前記端末間に設けられ、
     前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得手段と、
     前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定手段と、
     前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定手段と、
     予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、
     前記記憶手段の前記パケットデータと前記コンテンツリストを参照し、前記チャンク時間長推定手段で得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定手段で得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定手段と、
     を有することを特徴とするコンテンツ再生情報推定装置。
  8.  前記再生状態推定手段は、
     i番目の受信チャンクのダウンロード終了時刻と、i+1番目の受信チャンクのダウンロード開始時刻との間の期間を基に、一時停止の要因に係る閾値との比較を実施する一時停止要因推定手段を含む
     請求項7記載のコンテンツ再生情報推定装置。
  9.  前記再生状態推定手段は、
     前記パケットデータ取得手段において、前記ネットワークから前記パケットデータの受信が終了し、前記チャンク取得時刻及び前記チャンクの再生時間長が求められた後に再生状態の推定を実行する
     請求項7または8記載のコンテンツ再生情報推定装置。
  10.  前記チャンク時間長推定手段及び前記チャンク取得時刻推定手段は、
     前記パケットデータ取得手段において、パケットデータを取得する度に処理を実行し、
     前記再生状態推定手段は、
     前記端末において再生状態にあるとき、前記端末のバッファ中のチャンクを消費したとき、または、再生が停止状態であるときに新たにチャンクのデータを取得した時点で再生状態の推定を実行する
     請求項7または8記載のコンテンツ再生情報推定装置。
  11.  前記チャンク時間長推定手段は、
     前記パケットデータの受信バイト量及び再生レートから前記チャンクの再生時間長を求める手段を含む
     請求項7乃至10のいずれか1項に記載のコンテンツ再生情報推定装置。
  12.  配信サーバからネットワークを介して、コンテンツを端末に対して配信し、端末において該コンテンツを再生するシステムにおいて、前記配信サーバと前記端末間に設けられ、該コンテンツの再生に関する状態を推定するコンテンツ再生情報推定装置が実行するコンテンツ再生情報推定方法であって、
     前記配信サーバから前記端末に配信されるパケットデータを取得して、記憶手段に格納するステップと、
     前記取得したパケットデータに基づいて、前記端末におけるバッファ内のデータ量を推定するステップと、
     前記推定されたデータ量と所定の閾値とを比較することにより、前記端末における前記コンテンツの各時刻における再生に関する状態を推定するステップと
     を備えることを特徴とするコンテンツ再生情報推定方法。
  13.  ネットワークを介してコンテンツデータ配信を行う配信サーバと、前記配信サーバから受信したコンテンツデータを蓄積しながら再生する再生端末からなり、該再生端末が、該コンテンツデータを再生バッファに蓄積し、該再生バッファに初期バッファ量のコンテンツデータが蓄積されると再生を開始し、再生中は該再生バッファから再生に必要なデータを読み出し、該再生バッファに蓄積されたバッファ量が再生停止閾値を下回ると再生が停止し、該再生バッファに蓄積されたバッファ量が再生開始閾値を上回ると再生が開始する機能を有するシステムにおける、端末におけるコンテンツデータの再生停止状態の推定を行うコンテンツ再生情報推定方法であって、
     パケット情報取得手段が、前記ネットワークを介して送受信されるパケット情報を取得するパケット情報取得ステップと、
     コンテンツ受信量推定手段が、前記パケット情報の時系列情報に基づいて、前記再生端末にて各時刻に受信したコンテンツデータ量の時系列情報を推定するコンテンツ受信量推定ステップと、
     再生開始時間推定手段が、前記コンテンツ受信量推定ステップで推定された前記コンテンツデータ量を用いて、前記再生端末にて再生開始までに要した時間を推定する再生開始時間推定ステップと、
     再生状態推定手段が、前記コンテンツデータ量を用いて、前記再生端末の再生アプリケーションが再生開始後の各時間に消費するデータ量から前記再生端末にて各時刻における状態が再生状態または停止状態のいずれかにあるかを推定する再生状態推定ステップと、
     再生停止時間推定手段が、前記再生状態推定ステップにおいて停止状態と判断された場合の再生が停止された時間およびその長さを推定する再生停止時間推定ステップと、
     を有することを特徴とするコンテンツ再生情報推定方法。
  14.  配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定方法であって、
     前記配信サーバと前記端末間に設けられる装置において、
     パケットデータ取得手段が、前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得ステップと、
     チャンク時間長推定手段が、前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定ステップと、
     チャンク取得時刻推定手段が、前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定ステップと、
     再生状態推定手段が、予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、
     前記記憶手段の前記パケットデータと前記コンテンツリストを参照し、前記チャンク時間長推定ステップで得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定ステップで得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、
     該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定ステップと、
    を行う、ことを特徴とするコンテンツ再生情報推定方法。
  15.  前記再生状態推定ステップにおいて、
     i番目の受信チャンクのダウンロード終了時刻と、i+1番目の受信チャンクのダウンロード開始時刻との間の期間を基に、一時停止の要因に係る閾値との比較を実施する一時停止要因推定ステップを行う
     請求項14記載のコンテンツ再生情報推定方法。
  16.  コンピュータを、
     請求項1乃至11のいずれか1項に記載のコンテンツ再生情報推定装置の各手段として機能させるためのコンテンツ再生情報推定プログラム。
PCT/JP2012/078392 2011-11-02 2012-11-01 コンテンツ再生情報推定装置及び方法及びプログラム WO2013065804A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2013541848A JP5780684B2 (ja) 2011-11-02 2012-11-01 コンテンツ再生情報推定装置及び方法及びプログラム
US14/351,704 US9781474B2 (en) 2011-11-02 2012-11-01 Content playback information estimation apparatus and method and program
CN201280050761.7A CN103875218B (zh) 2011-11-02 2012-11-01 内容再生信息推测装置、方法
EP12846372.6A EP2775673B1 (en) 2011-11-02 2012-11-01 Content reproduction information estimating device, method and program

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2011-241173 2011-11-02
JP2011241173 2011-11-02
JP2012-031125 2012-02-15
JP2012031125 2012-02-15
JP2012-150926 2012-07-04
JP2012150926 2012-07-04

Publications (1)

Publication Number Publication Date
WO2013065804A1 true WO2013065804A1 (ja) 2013-05-10

Family

ID=48192142

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/078392 WO2013065804A1 (ja) 2011-11-02 2012-11-01 コンテンツ再生情報推定装置及び方法及びプログラム

Country Status (5)

Country Link
US (1) US9781474B2 (ja)
EP (1) EP2775673B1 (ja)
JP (2) JP5780684B2 (ja)
CN (1) CN103875218B (ja)
WO (1) WO2013065804A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015091012A (ja) * 2013-11-06 2015-05-11 日本電信電話株式会社 プログレッシブダウンロード型映像サービス品質推定装置及び品質推定方法
JP2015106897A (ja) * 2013-12-03 2015-06-08 日本電信電話株式会社 映像再生状態推定装置、映像再生状態推定方法、及びプログラム
JP2015154422A (ja) * 2014-02-18 2015-08-24 日本電信電話株式会社 映像再生状態推定装置、映像再生状態推定方法、及びプログラム
JP2015220640A (ja) * 2014-05-19 2015-12-07 日本電信電話株式会社 映像再生状態推定装置及び方法及びプログラム
JP2015228568A (ja) * 2014-05-30 2015-12-17 日本電信電話株式会社 映像品質推定装置及び方法及びプログラム
JP2016092528A (ja) * 2014-10-31 2016-05-23 日本電信電話株式会社 映像品質推定装置、方法およびプログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160164788A1 (en) * 2014-12-05 2016-06-09 Qualcomm Incorporated Egress Rate Shaping To Reduce Burstiness In Application Data Delivery
US10904312B2 (en) 2014-12-10 2021-01-26 Akamai Technologies, Inc. Server-side prediction of media client steady state
US9846650B2 (en) * 2015-03-09 2017-12-19 Samsung Electronics Co., Ltd. Tail response time reduction method for SSD
US10748646B2 (en) * 2016-12-30 2020-08-18 General Electric Company Chunk-wise transmission of time-series data to mobile devices
US10986001B2 (en) * 2018-01-25 2021-04-20 Nokia Solutions And Networks Oy System and method for quality of service detection of encrypted packet flows
WO2020158093A1 (ja) * 2019-02-01 2020-08-06 株式会社Nttドコモ 制御装置及び通信装置
CN113435749A (zh) * 2021-06-28 2021-09-24 上海华兴数字科技有限公司 一种工程设备调度方法及系统、一种工程设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006174231A (ja) * 2004-12-17 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> ストリーミング視聴品質管理装置,ストリーミング視聴品質制御装置,ストリーミング視聴品質管理方法,ストリーミング視聴品質制御方法,ストリーミング視聴品質管理プログラムおよびストリーミング視聴品質制御プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2006077728A1 (ja) * 2004-12-28 2008-06-19 ソフトバンクBb株式会社 テレビ放送視聴システム及びテレビ放送視聴方法
KR20110065100A (ko) * 2009-12-09 2011-06-15 삼성전자주식회사 멀티미디어 스트리밍 서비스를 지원하는 방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006174231A (ja) * 2004-12-17 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> ストリーミング視聴品質管理装置,ストリーミング視聴品質制御装置,ストリーミング視聴品質管理方法,ストリーミング視聴品質制御方法,ストリーミング視聴品質管理プログラムおよびストリーミング視聴品質制御プログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KOUHEI FUJIMOTO; SHINGO ATA; MASAYUKI MURATA: "Statistical Analysis of Packet delays in the Internet and Its Application to Playout Control for Streaming Applications", IEICE TRANSE. ON COMMUNICATION, vol. EOO-B, no. 6, June 2001 (2001-06-01)
R. PANTOS, ED.; W. MAY: "HTTP Live Streaming", IETF INTERNET-DRAFT, September 2011 (2011-09-01)
See also references of EP2775673A4 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015091012A (ja) * 2013-11-06 2015-05-11 日本電信電話株式会社 プログレッシブダウンロード型映像サービス品質推定装置及び品質推定方法
JP2015106897A (ja) * 2013-12-03 2015-06-08 日本電信電話株式会社 映像再生状態推定装置、映像再生状態推定方法、及びプログラム
JP2015154422A (ja) * 2014-02-18 2015-08-24 日本電信電話株式会社 映像再生状態推定装置、映像再生状態推定方法、及びプログラム
JP2015220640A (ja) * 2014-05-19 2015-12-07 日本電信電話株式会社 映像再生状態推定装置及び方法及びプログラム
JP2015228568A (ja) * 2014-05-30 2015-12-17 日本電信電話株式会社 映像品質推定装置及び方法及びプログラム
JP2016092528A (ja) * 2014-10-31 2016-05-23 日本電信電話株式会社 映像品質推定装置、方法およびプログラム

Also Published As

Publication number Publication date
EP2775673A4 (en) 2015-01-21
CN103875218B (zh) 2016-09-07
EP2775673A1 (en) 2014-09-10
EP2775673B1 (en) 2017-05-31
JP5875725B2 (ja) 2016-03-02
US20140241699A1 (en) 2014-08-28
JP2015228648A (ja) 2015-12-17
JP5780684B2 (ja) 2015-09-16
US9781474B2 (en) 2017-10-03
CN103875218A (zh) 2014-06-18
JPWO2013065804A1 (ja) 2015-07-30

Similar Documents

Publication Publication Date Title
JP5875725B2 (ja) コンテンツ再生情報推定装置及び方法及びプログラム
Ameigeiras et al. Analysis and modelling of YouTube traffic
CN105075276B (zh) 在广播通信网络中操作客户端设备和服务器设备的技术
US7886071B2 (en) Communication processing device, communication control method, and computer program
US8873590B2 (en) Apparatus and method for correcting jitter
RU2598805C2 (ru) Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
JP5938015B2 (ja) チャンクダウンロード完了判定装置、チャンクダウンロード完了判定方法、及びプログラム
JPWO2017135181A1 (ja) クライアント、サーバ、受信方法及び送信方法
TW201316814A (zh) 用於傳送及接收數位訊號之方法、傳送器、以及接收器
Gurel et al. Media over QUIC: Initial testing, findings and results
JP2011061533A (ja) コンテンツ配信システム、体感品質推定装置、方法、及び、プログラム
CN109194678B (zh) 基于redis消息队列的分布式流媒体服务系统
CN110881018B (zh) 媒体流的实时接收方法及客户端
JP5806982B2 (ja) ユーザポーズ操作時間推定装置及び方法及びプログラム
Ahsan et al. DASHing towards hollywood
JP5643242B2 (ja) メディアプレイヤパラメタ推定装置及び方法及びプログラム
JP6093317B2 (ja) ノンフリーズ型映像配信ネットワークシステム
KR101700370B1 (ko) 지터 보정 방법 및 장치
JP5806981B2 (ja) 再生状態推定装置及び方法及びプログラム
Shende et al. Cross-layer Network Bandwidth Estimation for Low-latency Live ABR Streaming
WO2018021950A1 (en) Device and method for controlling media streaming from a server to a client
Ahsan Video Streaming Transport: Measurements and Advances
US10051025B2 (en) Method and apparatus for estimating packet loss
JP2012257041A (ja) 通信装置、通信システム、通信方法及びプログラム
Shahbazian Characterization and Generation of Streaming Video Traces

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12846372

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013541848

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14351704

Country of ref document: US

REEP Request for entry into the european phase

Ref document number: 2012846372

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2012846372

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE