JP2005303927A - 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム - Google Patents

情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム Download PDF

Info

Publication number
JP2005303927A
JP2005303927A JP2004120716A JP2004120716A JP2005303927A JP 2005303927 A JP2005303927 A JP 2005303927A JP 2004120716 A JP2004120716 A JP 2004120716A JP 2004120716 A JP2004120716 A JP 2004120716A JP 2005303927 A JP2005303927 A JP 2005303927A
Authority
JP
Japan
Prior art keywords
information
unit
information processing
processing apparatus
transmission
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
JP2004120716A
Other languages
English (en)
Inventor
Yosuke Tamura
陽介 田村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2004120716A priority Critical patent/JP2005303927A/ja
Priority to US11/090,127 priority patent/US20050234892A1/en
Publication of JP2005303927A publication Critical patent/JP2005303927A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Abstract

【課題】クライアントが任意の位置でコンテンツデータのストリーミング配信を受けることができるようにする。
【解決手段】 クライアント４２は、第１の位置にいるとき、サーバ４１−１に対してコンテンツデータのストリーミング配信の要求を出す。サーバ４１−１は、コンテンツデータをクライアント４２にストリーミング配信する。クライアント４２は、サーバ４１−１とのコネクション情報を自ら管理する。クライアント４２は、第１の位置から第２の位置に移動したとき、それまでのサーバ４１−１とのコネクション情報に基づいて、連続するコンテンツデータのストリーミング配信を他のサーバ４１−２に要求する。サーバ４１−１，４１−２は、コンテンツデータを１GOPを１ユニットとするユニットに分割し、ユニットをさらにセグメントに分割してストリーミング配信する。本発明は、インターネットを介する情報処理システムに適用することが可能である。
【選択図】図３

Description

本発明は、情報処理システム、情報処理装置および方法、記録媒体、並びにプログラムに関し、特に、位置を移動しても、同一のコンテンツのストリーミング配信を続けて受けることができるようにした情報処理システム、情報処理装置および方法、記録媒体、並びにプログラムに関する。
最近、インターネットが普及し、サーバからクライアントに対してインターネットを介して各種のコンテンツが提供されるようになってきた。コンテンツを提供する形式に、プッシュ型とプル型とがある。また、コンテンツは、ファイルとして提供される場合と、ストリーミングとして提供される場合とがある。一般的に、ファイル単位でコンテンツを提供する場合、HTTP（Hyper Text Transfer Protocol）が利用され、ストリーミング配信を行う場合、Real-Time Protocol (RCT)（非特許文献１）が利用される。
コンテンツがファイルとして提供される場合、クライアントはそのファイルを構成する全てのデータを受信し、記憶してからそれを再生することができる。従って、そのファイルのサイズが大きい場合には、受信を開始してから再生を開始するまでの時間が比較的長くなることになる。
これに対して、ストリーミング配信の場合は、受信したデータをその範囲で再生することが可能であるため、リアルタイムでコンテンツを再生することが可能となる。
また、プッシュ型では、サーバがコンテンツ提供の状態を管理する。これに対してプル型では、クライアントが、コンテンツの受信状態を管理し、サーバはクライアントからの要求に基づいてデータを配信する。
プッシュ型でストリーミング配信を行う場合、例えば、図１に示されるような手順となる。すなわち、サーバ１１とクライアント１２との間でコネクションに関してコントロールが行われ、サーバ１１からクライアント１２に対して、コンテンツデータがストリーミング配信される。サーバ１１は、クライアント１２からストリーミング配信に関するフィードバック情報を得て、コネクション情報を管理する。コネクション情報に基づいて、クライアント１２に対して、何らかの理由によりコンテンツが受信されていないことが判明した場合、サーバ１１は、再度コンテンツを配信するなどの処理を行う。
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, January 1996
しかしながら、プッシュ型でストリーミング配信を行うと、サーバが、コンテンツをどこまで送信したかを管理しなければならず、サーバにかかる負荷が大きくなるという課題がある。また、クライアント１２が任意の位置に移動した結果、それまでのサーバからストリーミング配信を続けることが困難になることがある。このような場合、クライアントは、異なるサーバからそのコンテンツの提供を受ける必要があるが、そのためには、元のサーバから新しいサーバに、コネクション状態の管理を移行する必要がある。しかしながら、このような管理の移行は、事実上困難をともなうことが多く、結果的に、クライアントは、任意の位置に移動した場合、ストリーミング配信を受けることが困難になる課題がある。
本発明は、このような状況に鑑みてなされたものであり、クライアントが任意の位置に移動した場合にも、連続してストリーミング配信を受けることができるようにするものである。
請求項１の情報処理システムは、ネットワークを介して第１の情報処理装置から第２の情報処理装置に情報を提供する情報処理システムにおいて、前記第１の情報処理装置は、前記第２の情報処理装置から情報の提供の要求を受信する受信手段と、提供する前記情報としての１つのファイルを、単独で復号可能な処理単位に分割して、前記第２の情報処理装置に送信する送信手段とを備え、前記第２の情報処理装置は、前記第１の情報処理装置から送信されてきた前記情報を保持する保持手段と、前記保持手段に保持された前記情報を管理し、その保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求手段と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生手段とを備えることを特徴とする。
前記送信手段は、処理単位をさらに伝送単位に分割して、伝送単位で情報を送信し、第２の情報処理装置は、伝送単位で伝送されてきた情報を一時的に記憶する一時記憶手段をさらに備え、保持手段は、一時記憶手段に記憶された伝送単位が処理単位に達したとき、一時記憶手段に記憶された処理単位の転送を受け、保持するようにすることができる。
前記処理単位は、ユニットであり、伝送単位は、セグメントであるようにすることができる。
前記セグメントは、ネットワークで伝送の単位として使用されるパケットに収まる大きさであるようにすることができる。
請求項５の情報処理方法は、ネットワークを介して第１の情報処理装置から第２の情報処理装置に情報を提供する情報処理システムの情報処理方法において、前記第１の情報処理装置の情報処理方法は、前記第２の情報処理装置から情報の提供の要求を受信する受信ステップと、提供する前記情報としての１つのファイルを、単独で復号可能な処理単位に分割して、前記第２の情報処理装置に送信する送信ステップとを含み、前記第２の情報処理装置の情報処理方法は、前記第１の情報処理装置から送信されてきた前記情報を保持する保持ステップと、保持された前記情報の保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求ステップと、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップとを含むことを特徴とする。
請求項６の情報処理装置は、ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置において、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信手段と、前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信手段と、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信手段により新たな前記処理単位の要求が受信されたとき、前記送信手段に、新たな前記処理単位を前記伝送単位で伝送させる判定手段とを備えることを特徴とする。
前記処理単位は、ユニットであり、伝送単位は、セグメントであるようにすることができる。
前記セグメントは、ネットワークで伝送の単位として使用されるパケットに収まる大きさであるようにすることができる。
前記送信手段は、処理単位の送信の先頭のタイミングで、実質的に情報を含まない空のセグメントを送信するようにすることができる。
請求項１０の情報処理方法は、ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置の情報処理方法において、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップとを含むことを特徴とする。
請求項１１の記録媒体のプログラムは、ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置のプログラムであって、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップとを含むことを特徴とする。
請求項１２のプログラムは、ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置のプログラムであって、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップとをコンピュータに実行させることを特徴とする。
請求項１３の情報処理装置は、ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置において、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持手段と、前記保持手段に保持されている前記処理単位の保持量を判定する判定手段と、前記判定手段による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求手段と、前記他の情報処理装置に対する要求を管理する管理手段と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生手段とを備えることを特徴とする。
前記管理手段は、他の情報処理装置の識別情報、処理単位の提供を他の情報処理装置に要求した時刻、および保持手段に保持する予定の保持量を管理するようにすることができる。
前記要求手段は、保持手段に保持する予定の保持量を他の情報処理装置に通知し、情報処理装置は、他の情報処理装置に通知した保持量に基づいて、保持手段における保持量の予約量を更新する更新手段をさらに備えるようにすることができる。
前記処理単位は、ユニットであり、伝送単位は、セグメントであるようにすることができる。
前記セグメントは、ネットワークで伝送の単位として使用されるパケットに収まる大きさであるようにすることができる。
前記処理単位の送信の先頭のタイミングで、実質的に情報を含まない空のセグメントを受信したとき、処理単位の提供を他の情報処理装置に要求してから処理単位を受信するまでの時間を演算する演算手段をさらに備えるようにすることができる。
１つの処理単位を構成する全ての伝送単位が受信されるまで、伝送単位を一時的に保持する一時記憶手段と、１つの処理単位を構成する全ての伝送単位が一時記憶手段に記憶されたとき、１つの処理単位を構成する全ての伝送単位を、一時記憶手段から保持手段に転送する転送手段とをさらに備えるようにすることができる。
請求項２０の情報処理方法は、ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置の情報処理方法において、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、前記他の情報処理装置に対する要求を管理する管理ステップと、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップとを含むことを特徴とする。
請求項２１の記録媒体のプログラムは、ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置のプログラムであって、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、前記他の情報処理装置に対する要求を管理する管理ステップと、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップとを含むことを特徴とする。
請求項２２のプログラムは、ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置のプログラムであって、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、前記他の情報処理装置に対する要求を管理する管理ステップと、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップとをコンピュータに実行させることを特徴とする。
本発明の情報処理システムおよび方法においては、第１の情報処理装置が１つのファイルを単独で復号可能な処理単位に分割して、第２の情報処理装置に送信する。第２の情報処理装置は、第１の情報処理装置から送信されてきた情報を保持し、保持された情報を管理して、その保持量に応じて、続く情報の提供を第１の情報処理装置に要求する。第２の情報処理装置は、保持量が基準値より大きくなったとき、情報を処理単位で再生する。
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、他の情報処理装置から１つのファイルの単独で復号可能な処理単位毎の提供の要求が受信されたとき、処理単位の情報が、さらに伝送単位に分割され、伝送単位で他の処理装置に送信される。処理単位を構成する全ての伝送単位が送信されたとき、処理単位の送信が終了される。
本発明の他の情報処理装置および方法、記録媒体、並びにプログラムにおいては、伝送単位に分割して送信されてきた処理単位の情報が、処理単位で保持される。処理単位の保持量に基づいて、続く処理単位の提供が要求される。保持量が予め設定されている基準値より大きくなったとき、処理単位で再生が行われる。
本発明によれば、第１の情報処理装置から第２の情報処理装置に対して、情報をストリーミング配信することができる。特に、第２の情報処理装置が任意の位置に移動した場合においても、プル型で情報を確実にストリーミング配信することができる。
また、本発明によれば、他の情報処理装置に対して、情報をストリーミング配信することができる。特に、任意の位置に移動した他の情報処理装置に対して、簡単かつ確実にストリーミング配信を行うことが可能となる。
さらに、本発明によれば、他の情報処理装置からストリーミング配信を受けることが可能となる。特に、他の情報処理装置に大きな不可をかけることなく、任意の位置に移動した場合においても、移動前に受けていた情報と連続する情報のストリーミング配信を受けることが可能となる。
以下に本発明の最良の形態を説明するが、開示される発明と実施の形態との対応関係を例示すると、次のようになる。明細書中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
さらに、この記載は、明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現し、追加される発明の存在を否定するものではない。
請求項１の情報処理システムは、ネットワーク（例えば、図５のインターネット61）を介して第１の情報処理装置（例えば、図５のサーバ41-1）から第２の情報処理装置（例えば、図５のクライアント42）に情報を提供する情報処理システム（例えば、図５の情報処理システム40）において、前記第１の情報処理装置は、前記第２の情報処理装置から情報の提供の要求を受信する受信手段（例えば、図１８のステップS71の処理を実行する図１７の取得部411）と、提供する前記情報としての１つのファイルを、単独で復号可能な処理単位（例えば、ユニット）に分割して、前記第２の情報処理装置に送信する送信手段（例えば、図１８のステップS81の処理を実行する図１７の送信部415）とを備え、前記第２の情報処理装置は、前記第１の情報処理装置から送信されてきた前記情報を保持する保持手段（例えば、図２１のステップS124の処理を実行する図１１と図２０の遅延バッファ301）と、前記保持手段に保持された前記情報を管理し、その保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求手段（例えば、図１６のステップS31の判定結果に基づいて、ステップS37の処理を実行する図１４の送信部337）と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき（例えば、図２３のステップS151で遅延バッファの占有率が50％に達したと判定されたとき）、前記情報を前記処理単位で再生する再生手段（例えば、図２３のステップS152の処理を実行する図２２の再生部372）とを備えることを特徴とする。
前記送信手段は、処理単位をさらに伝送単位（例えば、セグメント）に分割して、伝送単位で情報を送信し、第２の情報処理装置は、伝送単位で伝送されてきた情報を一時的に記憶する一時記憶手段（例えば、図２０の一時記憶部366）をさらに備え、管理手段は、一時記憶手段に記憶された伝送単位が処理単位に達したとき（例えば、図２１のステップS118で、ユニットが完成したと判定されたとき）、一時記憶手段に記憶された処理単位の転送を受け、保持する（例えば、図２１のステップS124の処理）。
請求項５の情報処理方法は、ネットワーク（例えば、図５のインターネット61）を介して第１の情報処理装置（例えば、図５のサーバ41-1）から第２の情報処理装置（例えば、図５のクライアント42）に情報を提供する情報処理システム（例えば、図５の情報処理システム40）の情報処理方法において、前記第１の情報処理装置の情報処理方法は、前記第２の情報処理装置から情報の提供の要求を受信する受信ステップ（例えば、図１８のステップS71）と、提供する前記情報としての１つのファイルを、単独で復号可能な処理単位（例えば、ユニット）に分割して、前記第２の情報処理装置に送信する送信ステップ（例えば、図１８のステップS81）とを含み、前記第２の情報処理装置の情報処理方法は、前記第１の情報処理装置から送信されてきた前記情報を保持する保持ステップ（例えば、図２１のステップS124）と、保持された前記情報の保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求ステップ（例えば、図１６のステップS37）と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき（例えば、図２３のステップS151で遅延バッファの占有率が50％に達したと判定されたとき）、前記情報を前記処理単位で再生する再生ステップ（例えば、図２３のステップS152）とを含むことを特徴とする。
請求項６の情報処理装置は、ネットワーク（例えば、図５のインターネット61）を介して他の情報処理装置（例えば、図５のクライアント42）から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置（例えば、図５のサーバ41-1）において、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位（例えば、ユニット）毎の提供の要求を受信する受信手段（例えば、図１８のステップS71の処理を実行する図１６の取得部411）と、前記処理単位をさらに伝送単位（例えば、セグメント）に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信手段（例えば、図１８のステップS81の処理を実行する図１７の送信部415）と、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信手段により新たな前記処理単位の要求が受信されたとき、前記送信手段に、新たな前記処理単位を前記伝送単位で伝送させる判定手段（例えば、図１８のステップS82の処理を実行する図１７の判定部413）とを備えることを特徴とする。
前記送信手段は、処理単位の送信の先頭のタイミングで、実質的に情報を含まない空のセグメントを送信する（例えば、図１８のステップS79，S81の処理）。
請求項１０の情報処理方法、請求項１１の記録媒体のプログラム、請求項１２のプログラムは、ネットワーク（例えば、図５のインターネット61）を介して他の情報処理装置（例えば、図５のクライアント42）から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置（例えば、図５のサーバ41-1）の情報処理方法において、前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位（例えば、ユニット）毎の提供の要求を受信する受信ステップ（例えば、図１８のステップS71）と、前記処理単位をさらに伝送単位（例えば、セグメント）に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップ（例えば、図１８のステップS81）と、前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップ（例えば、図１８のステップS82）とを含むことを特徴とする。
請求項１３の情報処理装置は、ネットワーク（例えば、図５のインターネット61）を介して他の情報処理装置（例えば、図５のサーバ41-1）に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置（例えば、図５のクライアント42）において、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位（例えば、ユニット）に分割し、前記処理単位を、さらに前記ネットワークの伝送単位（例えば、セグメント）毎に分割して送信してきた前記情報を、前記処理単位で保持する保持手段（例えば、図２１のステップS124の処理を実行する図１１と図２０の遅延バッファ301）と、前記保持手段に保持されている前記処理単位の保持量を判定する判定手段（例えば、図１６のステップS31の処理を実行する図１４の判定部332）と、前記判定手段による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求手段（例えば、図１６のステップS37の処理を実行する図１４の送信部337）と、前記他の情報処理装置に対する要求を管理する管理手段（例えば、図１６のステップS35の処理を実行する図１４の保存部335）と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき（例えば、図２３のステップS151で遅延バッファの占有率が50％に達したと判定されたとき）、前記情報を前記処理単位で再生する再生手段（例えば、図２３のステップS152の処理を実行する図２２の再生部372）とを備えることを特徴とする。
前記管理手段は、他の情報処理装置の識別情報（例えば、サーバ41-1のID）、処理単位の提供を他の情報処理装置に要求した時刻（例えば、ヘッダhdr_tstmpに記述するタイムスタンプ）、および保持手段に保持する予定の保持量（例えば、ヘッダhdr_abufに記述する通知バッファサイズ）を管理する。
前記要求手段は、保持手段に保持する予定の保持量（例えば、式（１）と式（２）の演算結果のうちの小さい方を）を他の情報処理装置に通知し（例えば、図１６のステップS34の処理）、前記情報処理装置は、他の情報処理装置に通知した保持量に基づいて、保持手段における保持量の予約量（例えば、変数gcb_rsvbufの予約済みのバッファサイズ）を更新する更新手段（例えば、図１６のステップS36の処理を実行する図１４の更新部336）をさらに備える。
前記処理単位の送信の先頭のタイミングで、実質的に情報を含まない空のセグメントを受信したとき（例えば、図２１のステップS111で、hdr_typeがINITSEGであると判定されたとき）、処理単位の提供を他の情報処理装置に要求してから処理単位を受信するまでの時間（例えば、ラウンドトリップタイムRTT）を演算する演算手段（例えば、図２１のステップS114の処理を実行する図２０の更新部363）をさらに備える。
１つの前記処理単位を構成する全ての伝送単位が受信されるまで、伝送単位を一時的に保持する一時記憶手段（例えば、図２０の一時記憶部366）と、１つの処理単位を構成する全ての伝送単位が一時記憶手段に記憶されたとき（例えば、図２１のステップS118で、ユニットが完成したと判定されたとき）、１つの処理単位を構成する全ての伝送単位を、一時記憶手段から保持手段に転送する転送手段（例えば、図２１のステップS124の処理を実行する図２０の格納部364）とをさらに備える。
請求項２０の情報処理方法、請求項２１の記録媒体のプログラム、並びに請求項２２のプログラムは、ネットワーク（例えば、図５のインターネット61）を介して他の情報処理装置（例えば、図５のサーバ41-1）に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置（例えば、図５のクライアント42）の情報処理方法において、前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位（例えば、ユニット）に分割し、前記処理単位を、さらに前記ネットワークの伝送単位（例えば、セグメント）毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップ（例えば、図２１のステップS124）と、前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップ（例えば、図１６のステップS31）と、前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップ（例えば、図１６のステップS37）と、前記他の情報処理装置に対する要求を管理する管理ステップ（例えば、図１６のステップS35）と、前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき（例えば、図２３のステップS151で遅延バッファの占有率が50％に達したと判定されたとき）、前記情報を前記処理単位で再生する再生ステップ（例えば、図２３のステップS152）とを含むことを特徴とする。
以下、本発明の実施の形態について説明する。図２は、本発明を適用した情報処理システムの構成例を表している。この情報処理システム４０は、サーバ４１とクライアント４２により構成されている。クライアント４２は、サーバ４１に対して、コンテンツデータのストリーミング配信の要求を送信し、サーバ４１は、この要求に応じてコンテンツデータをクライアント４２に対してストリーミング配信する。
すなわち、本発明においては、プル型のストリーミング配信が行われる。その結果、図３に示されるように、クライアント４２は、図中左側に示される第１の位置において、サーバ４１−１からコンテンツデータのストリーミング配信を受けている状態から、図中右側に示される第２の位置に移動した場合においても、クライアント４２は、同一のコンテンツを有する異なるサーバ４２−２から、それまでのコンテンツデータに続くコンテンツデータのストリーミング配信を受けることが可能となる。
図４には、この様子が、拡張して示されている。すなわち、本発明においては、図４に示されるように、サーバ４１−１乃至４１−５のいずれからも、クライアント４２はコンテンツデータのストリーミング配信を受けることが可能な、マルチホームのマルチサーバシステムが実現される。
具体的には、本発明においては、図５に示されるように、情報処理システムが構成される。すなわち、情報処理システム４０は、インターネット６１に接続されているサーバ４１−１乃至４１−３と、インターネット６１に接続されているクライアント４２とにより構成される。図５に示されるように、クライアント４２は、必要に応じて、任意の位置に移動可能である。そして、クライアント４２は、任意の位置で、サーバ４１−１乃至４１−３のいずれかから連続して、ストリーミング配信を受けることができる。換言すれば、サーバ４１−１乃至４１−３（以下、これらを個々に区別する必要がない場合、単にサーバ４１と称する）は、同一のコンテンツをプル型でストリーミング配信する機能を有している。
図６は、サーバ４１の構成例を表している。
図６において、CPU（Central Processing Unit）１２１は、ROM（Read Only Memory）１２２に記憶されているプログラム、または記憶部１２８からRAM（Random Access Memory）１２３にロードされたプログラムに従って各種の処理を実行する。RAM１２３にはまた、CPU１２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU１２１、ROM１２２、およびRAM１２３は、バス１２４を介して相互に接続されている。このバス１２４にはまた、入出力インタフェース１２５も接続されている。
入出力インタフェース１２５には、キーボード、マウスなどよりなる入力部１２６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部１２７、ハードディスクなどより構成される記憶部１２８、モデムなどより構成される通信部１２９が接続されている。通信部１２９は、インターネット６１を含むネットワークを介しての通信処理を行う。
入出力インタフェース１２５にはまた、必要に応じてドライブ１３０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１３１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２８にインストールされる。
サーバ４１の記憶部１２８には、図７に示されるようなマッピング情報が予め記憶されている。このマッピング情報は、オリジナルコンテンツＣ0を、異なるビットレートでエンコードしたエンコードコンテンツと、それに付随する情報とにより構成されている。図７の例においては、オリジナルコンテンツＣ0を32kbpsでエンコードしたエンコードコンテンツＣ1、64kbpsでエンコードしたエンコードコンテンツＣ2、128kbpsでエンコードしたエンコードコンテンツＣ3、並びに256kbpsでエンコードしたエンコードコンテンツＣ4の４種類のエンコードコンテンツがマッピング情報とされている。
各エンコードコンテンツＣ1乃至Ｃ4は、単独でデコード（復号）可能な処理単位（ユニット）に分割されて保持される。このユニットは、コンテンツが、例えば、Motion-JPEG（Joint Photographic Experts Group）でエンコードされている場合、フレームとすることができる。M-JPEG方式の場合、フレーム単位でエンコードが行われるため、フレーム単位でデコードが可能であるからである。
また、MPEG（Moving Picture Experts Group）でエンコードされている場合、１GOP（Group of Pictures）を１ユニットとすることができる。MPEG方式でエンコードされている場合、GOPを単位としてエンコードが行われているため、GOPを単位として復号が可能であるからである。
すなわち、図８に示されるように、GOPは、Ｉピクチャ、Ｐピクチャ、およびＢピクチャの３種類の方式でエンコードされたフレームで構成される。Ｉピクチャは、他のフレームとの相関に基づかずにエンコードが行われたフレームであり、そのフレーム自体でデコードが可能である。これに対して、Ｐピクチャは、時間的に前のＩピクチャまたはＰピクチャを参照してエンコードされたフレームであり、参照先のＩピクチャまたはＰピクチャが先にデコードされないと、そのフレームをデコードすることができない。さらに、Ｂピクチャは、時間的に前のフレームと後のフレームとを参照してエンコードがなされたフレームであり、それぞれ参照された時間的に前、または時間的に後のフレームのデコードが行われた後でないと、そのフレームのデコードを行うことができない。
メインプロファイル形式の場合、図８に示されるように、ＩピクチャまたはＰピクチャの間に２個のＢピクチャが配置されている。
図９は、MPEG４の方式でエンコードされた１GOPのフレームの構成例を表している。この構成例においては、１３フレームで１GOPが構成され、１GOPの中には、２枚のＩピクチャ、３枚のＰピクチャ、および８枚のＢピクチャが含まれている。
図１０は、クライアント４２の構成例を表している。その基本的構成は、図６におけるサーバ４１と同様である。すなわち、クライアント４２も、CPU２２１乃至リムーバブルメディア２３１により構成され、これらは、サーバ４１におけるCPU１２１乃至リムーバブルメディア１３１と同様の機能と構成を有している。すなわち、図１０における各部は、図６における同一の名称の各部と同一の機能を有している。
クライアント４２のRAM２２３には、図１１に示される遅延バッファ３０１が形成される。クライアント４２は、この遅延バッファ３０１に、理想的に１０個のユニットのデータが格納されるものとして、コンテンツデータの管理を行う。
RAM２２３にはまた、コンテンツデータの授受の管理を行うためのステータス情報として、図１２に示される変数が記憶される。
変数ucb_***（***は、任意の文字列を意味する）は、ユニット数単位で保持される変数（Per-Unit Variables）であり、変数scb_***は、サーバ数単位で保持される変数（Per-Server Variables）であり、変数gcb_***は、グローバルな変数（Unique Variables）を表す。
変数ucb_sidには、ユニット要求パケットを送信するサーバを識別するサーバIDが記述される。変数ucb_timeには、要求パケットを送信した時刻が記述される。変数ucb_rbufには、予約済みの通知バッファサイズが記述される。変数ucb_initには、初期セグメントの受信時刻が記述される。変数ucb_recvには、対象ユニットの、それまでに受信されたセグメントの全受信データ量が記述され、変数ucb_nsegには、そのユニットの全セグメント数が記述される。変数ucb_csegには、対象ユニットの、それまでに受信されたセグメントの全受信セグメント数が記述される。変数ucb_sampleは、初期セグメントが最初に届いたか否かを表すフラグである。このフラグは、そのユニットに基づいて、後述するラウンドトリップタイム（RTT）を計算するか否か（サンプリングの可否）を表すフラグともなる。
変数scb_rttには、予測ラウンドトリップタイムが記述され、変数scb_bandには、ボトルネックリンクの予測帯域幅が記述される。変数scb_lossには、予測ロス率が、変数scb_lackには、BUFLACKタイプのセグメントの受信数が、それぞれ記述される。
変数gcb_curbufには、所定のタイミングにおける（現在の）バッファサイズが記述され、変数gcb_rsvbufには、予約済みのバッファサイズが記述される。変数gcb_playunitには、再生ユニットの番号が、そして変数gcb_requnitには、要求ユニットが複数個ある場合には、そのうちの最大の番号が（従って、１個の場合はその番号が）、それぞれ記述される。
図１３は、このクライアント４２とサーバ４１との間で受信されるパケットのヘッダに記述される情報を表している。ヘッダhdr_typeは、パケットの種類を表し、REQUEST，INITSEG，DATASEG，またはBUFLACKのいずれかが記述される。REQUESTは、そのパケットがデータを要求する要求パケットであることを表す。INITSEGは、そのパケットが初期セグメントのパケットであることを表す。DATASEGは、そのパケットがデータセグメントのパケットであることを表す。BUFLACKは、そのパケットが、遅延バッファ３０１に記憶されるデータが、不足する結果となるおそれがあるデータ量のパケットであることを通知する。
ヘッダhdr_cidには、コンテンツを識別するコンテンツIDが記述され、ヘッダhdr_uidには、ユニットを識別するユニットIDが記述される。ヘッダhdr_tstmpには、そのセグメントの送信時刻を表すタイムスタンプが記述され、ヘッダhdr_segnoには、そのパケットで要求するセグメントの連続番号が記述される。ヘッダhdr_nsegには、そのユニットを構成するセグメントの数が記述され、ヘッダhdr_abufには、通知バッファサイズがバイト数で記述される。そして、ヘッダhdr_lenには、そのパケットで要求するセグメントのデータ長がバイト数で記述される。
本発明が提供するプロトコルである3SP（Stateless Server Streaming Protocol）では、各クライアント自らが取得したいコンテンツを有するサーバのリストを予め保持している。そして、クライアントは、そのサーバに対して、コンテンツIDでコンテンツを指定し、ユニットIDでユニットを指定し、そのユニットの要求パケットを送信する。リスト中にサーバが複数ある場合、各クライアントはプルーブパケットをサーバに送信し、その返答から遅延を測定し、遅延の小さなサーバを選択して、そのサーバに対してユニット要求パケットを送信する。
クライアント４２は、サーバ４１に対して、所定時間毎にユニットを要求するパケットを送信する。この処理、および後述する図１６のフローチャートに示されるユニット要求パケット送信処理を実行するために、クライアント４２は、図１４に示されるような機能的構成を有している。すなわち、クライアント４２は、計時部３３１、判定部３３２、設定部３３３、生成部３３４、保存部３３５、更新部３３６、送信部３３７、開放部３３８、および初期化部３３９を有している。
計時部３３１は、計時動作を行う。判定部３３２は、一定時間計時されたか否か、終了がユーザより指示されたか否かといった判定のほか、遅延バッファ３０１の利用率や、再送すべきユニット番号が存在するか否かといった判定処理を行う。
設定部３３３は、変数に各種の値を設定する。生成部３３４は、ユニット要求パケットのヘッダを作成する。保存部３３５は、サーバ４１とのコネクションの情報を保存する。更新部３３６は予約バッファ量や予測ロス率の更新をする。送信部３３７は、ユニット要求パケットを送信する処理を行う。開放部３３８は、予約領域を開放する処理を行う。初期化部３３９は、ステータス情報のうち、ユニット数単位で保持される変数に関する情報の初期化処理を行う。
次に、図１５のフローチャートを参照して、クライアント４２が実行する送信タイマ処理を説明する。この処理は、クライアント４２のユーザが、入力部２２６を操作することでサーバ４１にアクセスし、コンテンツのストリーミング配信の受信を指令したとき、開始される。
ステップＳ１１において、計時部３３１は、計時動作を開始する。ステップＳ１２において、判定部３３２は、一定時間計時したか否かを判定する。すなわち判定部３３２は、ステップＳ１１で計時動作を開始してから予め設定してある一定時間が経過したか否かを判定し、一定の時間が経過するまで待機する。この一定の時間は、例えば、500ミリ秒とされる。この一定の時間は、ストリーミング配信を受けるコンテンツの１ユニットの再生時間より充分短い時間とされる。本実施の形態においては、MPEG４の１GOPが１ユニットとされる。この１GOPの典型的な最小値は、約１秒であるので、一定時間を500ミリ秒とすれば、それに比べて充分短い時間となる。
ステップＳ１２において、一定時間が経過したと判定された場合、ステップＳ１３において、判定部３３２は、送信タイミング信号を出力する。この送信タイミング信号が出力される毎に、後述する図１６のユニット要求パケット送信処理が実行される。従って、本実施の形態の場合、500ミリ秒毎に、後述する図１６のユニット要求パケット送信処理が実行されることになる。
ステップＳ１４において、判定部３３２は、ユーザより終了が指示されたか否かを判定し、終了が指示されていない場合には、処理はステップＳ１１に戻り、それ以降の処理が繰り返し実行される。ステップＳ１４において、終了が指示されたと判定された場合、送信タイマ処理が終了される。
次に、図１６のフローチャートを参照して、クライアント４２が実行するユニット要求パケット送信処理について説明する。この処理は、図１５のステップＳ１３で送信タイミング信号が出力されたタイミング毎に、繰り返し実行される。
ステップＳ３１において、判定部３３２は、遅延バッファの利用率が90％以下か否かを判定する。利用率は、遅延バッファ３０１の最大値Bmaxに対する予約量Brsvと現在の容量Bcurとの和の割合（（Brsv＋Bcur）／Bmax）を意味する。
現在のバッファ量Bcurは、後述する図２１のステップＳ１２４において、変数gcb_curbufに設定されている値に対応するものであり、その時点において遅延バッファ３０１に保存されているデータ量を表す。
予約量Brsvは、図２１のステップＳ１２３において、変数gcb_rsvbufに設定される値に対応し、前回の要求パケットで要求したユニットのデータ量を表す。この予約量Brsvは、前回、下記式（１）で演算された通知バッファ量Badvに対応する。換言すれば、新たな通知バッファサイズ量Badvがサーバ４１に通知されると、前回の通知バッファ量サイズBadvが、予約量Brsvとされる（後述する図１６のステップＳ３５）。
Figure 2005303927
ステップＳ３１において、遅延バッファ３０１の利用率が90％以下ではないと判定された場合、処理は終了される、すなわち、この場合には、遅延バッファ３０１に充分なコンテンツデータが保存されているので、さらなるコンテンツデータの要求は行われない。そして、次の500ミリ秒後のタイミングまで、処理は中断されることになる。
ステップＳ３１において、遅延バッファ３０１の利用率が90％以下であると判定された場合、ユニット要求パケットを送信する処理が次のように行われる。すなわち、この場合には、ステップＳ３２において、判定部３３２は、TCP（Transmission Control Protocol）のラウンドタイムアウト（Round Timeout(RTO)）が経過している再送すべきユニット番号ｉが存在するか否かを判定する。すなわち、過去にユニット番号ｉの送信を、後述するステップＳ３７の処理で要求しているにも関わらず、まだ受信していないユニットが存在するか否かが判定される。
具体的には、タイムアウト値RTOは、変数scb_rttに記述されている予測ラウンドトリップタイムの４倍の値が利用される。ユニット番号ｉに関して、変数ucb_timeに計時されている要求パケット送信時刻と、現在時刻との差から経過時間が演算され、この経過時間がタイムアウト値RTOより大きければ、そのユニット番号ｉが存在すると判定される。
ただし、ユニット番号ｉの値は、変数gcb_playunitの値より小さい必要がある。すなわち、変数gcb_playunitには、後述する図２３のステップＳ１５２で再送すべき再生ユニットの番号が記述されており、その再生ユニットの番号よりユニット番号ｉが大きければ、最早、そのユニットは、再生する機会がない。そこで、そのようなユニット番号ｉは、存在しないものと判定される（無視される）。これにより、ユニットの送信要求が無駄に行われることが防止される。
再送すべきユニット番号ｉが存在しない場合には、ステップＳ３３において、設定部３３３は、要求ユニット番号ｎに変数gcb_requnitを設定する。変数gcb_requnitには、要求ユニットの最大の番号が設定されているため、この最大の番号が、要求ユニットｎに設定されることになる。従って、要求すべきユニットが複数個存在する場合には、より時間的に新しいユニットが優先的に要求される、これにより、最新のユニットの欠落による画像の途切れが防止される。
次に、ステップＳ３４において、生成部３３４は、ユニット要求パケットのヘッダを作成する。具体的には、要求するコンテンツのコンテンツIDが、ヘッダhdr_cidに格納され、要求するユニットのユニットIDが、ヘッダhdr_uidに格納される。このユニットIDは、変数gcb_requnitから取得される。また、計時部３３１が計時している現在時刻が、ヘッダhdr_tstmpにタイムスタンプとして格納される。
さらに、生成部３３４は、上述した式（１）に基づいて、通知バッファ量（Advertised buffer Size）Badvを演算するとともに、次の式（２）に基づいて、TFRを演算し、両者のうちの小さい方を選択し、ヘッダhdr_abufに設定する。
式（１）における時間Ｔintは、１ユニット分の再生時間を表し、時間Ｔprefは、遅延バッファ３０１が保持可能な全ユニットの再生時間を表す。本実施の形態の場合、遅延バッファ３０１には、１０個分のユニットが保存されるものとされているため、時間Ｔprefは、時間Ｔintの１０倍の値に設定される。従って、式（１）におけるＴpref／Ｔintの値は、「１０」となる。
値Cuntは、遅延バッファ３０１にその時点において保存されているユニットの数を表し、各図１１の例の場合、６個（値Bcurは、それをデータ量（バイト）で表した値）である。また、値Crsvは、予約量Brsv（バイト）をユニットの数で表したものである。
従って、式（１）は、遅延バッファ３０１を理想的なユニット数（１０個）に保つために、使われていない遅延バッファ３０１の領域（Bmax−Bcur− Brsv）を、足りないユニットの数（Ｔpref／Ｔint−（Cunt＋Crsv））で割り算することによって求められる値である。
輻輳制御を行わない場合には、上述した式（１）に基づいて演算された値Badvがそのままヘッダhdr_abufに記述される。しかし、本発明においては、TCPの信頼性の高い輻輳制御のモデルとして、TCPフレンドリーレートコントロール（TCP Friendly Rate Control（TFRC））として知られているものが利用される。そこで、本発明においては、次の式（２）で表されるTFR（TCP Friendly Rate）が演算される。そして、式（１）と式（２）で表される値のうち、小さい方が通知バッファ量としてヘッダhdr_abufに記述される。
Figure 2005303927
なお、式（２）において、ｓはパケットサイズ（バイト）、ＲはRTT（秒）、ｐはロス率、ＴRTOは、TCPのタイムアウト値（秒）を意味する。ロス率ｐは、１ラウンド、すなわち、ユニット要求パケットを送信してから、そのユニットが受信されるまで毎に算出されたサンプルに基づいて、加重平均により導かれる値である。要求パケットのロスは、バックオフによる輻輳制御がされるため、ロス率には反映させない。
要求パケットの送信間隔でのTFRを利用しているのは、要求パケットの送信間隔内でボトルネックのリンクが処理できないということは、データ取得速度よりも、再生速度の方が速くなっていることを意味するからである。例え、遅延バッファ３０１により、再生時間に間に合ったとしても、データ時間が長くなるほど、バッファリングが追いつかなくなり、クライアント４２の再生が途切れる可能性がある。そこで、本発明の３SPでは、基本的に、バッファリングをあてにした転送は行わない。
このように、TFRを考慮することで、インターネット６１におけるトラフィックが混雑し、他の装置の通信が必要以上に影響を受けることが抑制される。
次に、ステップＳ３５において、保存部３３５は、コネクションの情報を保存する処理を行う。すなわち、この実施の形態においては、プル型でストリーミング配信が行われるため、クライアント４２は、サーバ４１とのコネクションを自ら管理する。具体的には、クライアント４２がアクセスしたサーバのIDが、変数ucb_sidに格納される。さらに、ヘッダhdr_tstmpに設定されているタイムスタンプ（ステップＳ３４の処理で現在時刻が設定されている）が変数ucb_timeに格納され、ヘッダhdr_abufの値が変数ucb_rbufに保存される。これにより、ステップＳ３４で、ヘッダhdr_abufに格納された通知バッファ量BadvまたはTFRが、変数ucb_rbufに格納される。
ステップＳ３６において、更新部３３６は、予約バッファ量を更新する。具体的には、予約済みのバッファサイズを表す変数gcb_rsvbufの値に、予約済みの通知バッファサイズを表す変数ucb_rbufの値が累積加算される。
次に、ステップＳ３７において、送信部３３７は、ステップＳ３４で生成したユニット要求パケットをサーバ４１に送信する。このユニット要求パケットは、インターネット６１を介してサーバ４１に送信される。
ステップＳ３２において、ラウンドトリップタイムのタイムアウト値RTOが経過している再送すべきユニット番号ｉが存在すると判定された場合、ステップＳ３８において、更新部３３６は、全受信セグメント数を表す変数ucb_csegと、全セグメント数を表す変数ucb_nsegを利用して、ロス率をサンプル計算する。また、更新部３３６は、加重平均により予測ロス率を表す変数scb_lossを更新する。
例えば、変数ucb_nseg[i]で表される全セグメント数が１０個であるユニットの受信処理中に、変数ucb_cseg[i]で表されるセグメント数が８個である時点で、タイムアウトしたとする。この場合、変数ucb_sid[i]でそのIDが表される要求サーバのロス率のサンプルは、次式で表される。
（ucb_nseg[i]−ucb_cseg[i]）／ucb_nseg[i]＝（10-8）／10＝0.2 ・・・（３）
変数scb_loss[ucb_sid[i]]で表されるロス率は、次式のように加重平均により更新される。
scb_loss[ucb_sid[i]]＝scb_loss[ucb_sid[i]]×（1−α）＋0.2×α ・・・（４）
なお、加重平均に利用される定数αは、０より大きく、１より小さい値、例えば、0.9とされるが、それ以外の値を用いることも、もちろん可能である。
ステップＳ３９において、開放部３３８は、予約領域を開放する。具体的には、予約済みのバッファサイズを表す変数gcb_rsvbufから、予約済みの通知バッファサイズを表す変数ucb_rbufの値が減算される。すなわち、ステップＳ３６の処理で加算された値の分だけここで減算が行われる。
次に、ステップＳ４０において、初期化部３３９は、図１２に示されるユニット数単位で保持される変数（Per-Unit Variables）を全て初期化する。すなわち、変数ucb_sid，ucb_time，ucb_rbuf，ucb_init， ucb_recv，ucb_nseg，ucb_cseg，ucb_sampleが全て初期化される（例えば、０とされる）。
ステップＳ４１において、設定部３３３は、要求ユニット番号ｎにｉを設定する。その後、ステップＳ３４において、その要求ユニット番号ｎのヘッダが作成され、ステップＳ３５において、コネクションの情報が保存され、ステップＳ３６において、予約バッファ量の更新が行われ、ステップＳ３７において、そのユニット要求パケットが送信される。
以上のようなクライアント４２によるユニット要求パケットの送信処理に対応して、サーバ４１は、ユニット要求パケット受信処理を実行する。この処理のため、サーバ４１は、図１７に示されるような機能的構成を有している。
すなわち、サーバ４１は、取得部４１１、指定部４１２、判定部４１３、選択部４１４、送信部４１５、読み込み部４１６、および生成部４１７を有している。
取得部４１１は、クライアント４２から送信されてきたユニット要求パケットを受信し、そこに含まれる必要なデータを取得する。また、取得部４１１は、マッピング情報から異なるビットレートのファイルポインタやユニット情報を取得したり、取得ファイルのユニットのサイズを取得したりする処理を実行する。指定部４１２は、比較ファイルに最大ビットレートのファイルを指定したり、ヘッダに各種のデータを指定したりする。
判定部４１３は、ユニットのサイズを判定したり、ファイルの有無を判定したり、ヘッダの値を判定する処理を実行する。選択部４１４は、異なるビットレートのファイルを選択する。送信部４１５は、セグメントを送信する処理を実行する。読み込み部４１６は、ユニットをファイルから読み込む処理を実行する。生成部４１７は、セグメントを生成する処理を実行する。
次に、図１８のフローチャートを参照して、サーバ４１が行うユニット要求パケット受信処理を説明する。この処理は、上述したクライアント４２からのユニット要求パケットが送信されてきたとき、これに対応して実行される。
ステップＳ７１において、取得部４１１は、クライアント４２から送信されてきたユニット要求パケットを受信する。そして、取得部４１１は、そのユニット要求パケットのヘッダ内のhdr_cidに記述されているコンテンツIDに対応するマッピング情報を取得する。このヘッダhdr_cidは、図１６のステップＳ３４において作成されたものである。
ステップＳ７２において、取得部４１１は、ステップＳ７１の処理で取得したマッピング情報から、異なるビットレートのファイルポインタとユニット情報を取得する。マッピング情報としては、図７を参照して上述したように、４種類のビットレートのファイルが用意されているので、ファイルポインタとしては、この４つのファイルを指定するポインタが取得される。また、各ファイルは、ユニット毎に分割されているので、そのファイルのどのユニットを指示するのかのポインタも取得される。なお、ユニット要求パケットのヘッダから取得されるユニット情報とは、ヘッダhdr_uidに記述されているユニットID、ヘッダhdr_abufに記述されている通知バッファサイズなどである。
ステップＳ７３において、指定部４１２は、比較ファイルとして最大ビットレートのファイルを指定する。この実施の形態においては、図７に示されるように、256kbpsのビットレートのエンコードコンテンツが、最大ビットレートのファイルであるので、これが比較ファイルとして指定される。
ステップＳ７４において、取得部４１１は、ステップＳ７３で指定された比較ファイルのユニットであって、ヘッダhdr_uidに記述されているユニットIDのユニットのサイズを取得する。このサイズは、サーバ４１がこの最大ビットレートのエンコードコンテンツＣ4を生成するときに、予め同時に生成され、マッピング情報として記憶されているものである。
ステップＳ７５において、判定部４１３は、ユニットのサイズはヘッダhdr_abuf以下か否かを判定する。すなわち、ステップＳ７４で取得されたユニットのサイズが、ステップＳ７２で取得されたヘッダhdr_abufに記述されている通知バッファサイズ以下であるか否かが判定される。ユニットのサイズがヘッダhdr_abufに記述されている通知バッファサイズ以下である場合には、そのユニットをクライアント４２に送信しても、クライアント４２がそれを遅延バッファ３０１に保持し、適正に処理することが可能である。従って、この場合、ステップＳ７６において、読み込み部４１６は、ヘッダhdr_uidに記述されているユニットIDのユニットを、ファイルから読み込む処理を実行する。これにより、クライアント４２から送信されてきたユニット要求パケットのヘッダに記述されていたユニットが、そのファイルから読み込まれる。そして、読み込み部４１６は、セグメントの連続番号を表すヘッダhdr_segnoに０を書き込む。
次に、ステップＳ７７において、生成部４１７は、セグメントを生成する。具体的には、生成部４１７は、ユニットを複数のセグメントに分割する。もちろん、既に分割が行われている場合には、実質的に既に存在する複数のセグメントの中から、１つのセグメントを選択する処理が行われる。さらに生成部４１７は、ユニット要求パケットのヘッダhdr_nsegに、このユニットの全セグメントの数を設定する。また、生成部４１７は、ヘッダhdr_segnoに、生成部４１７は、セグメントの連続番号を記述する。いまの場合、ステップＳ７６において、ヘッダhdr_segnoに０が初期設定されているため、０が記述される。さらに、生成部４１７は、ヘッダhdr_lenに、そのセグメントのデータ長を記述する。
ヘッダhdr_segnoの値が０である場合、送信されるセグメントは初期セグメントであるため、実質的にはデータは存在しない。すなわち、空のセグメントとなるので、ヘッダhdr_lenには０が設定される。これらの全セグメントの数、データ長なども、サーバ４１が保持するマッピング情報に予め記述されているものである。
次に、ステップＳ７８において、判定部４１３は、ヘッダhdr_segnoの値が０であるか否かを判定する。いまの場合、この値は０であるから、ステップＳ７９において、指定部４１２は、ヘッダhdr_typeにINITSEGを指定する。すなわち、いま生成しているセグメントは、初期セグメントであることがヘッダに記述される、そして、ステップＳ８１において、送信部４１５は、セグメントを送信する。このセグメントは、１つのパケットとして、送信される。
このようにして、図１９に示されるように、クライアント４２からサーバ４１に対して、ユニット要求パケットが送信された場合、サーバ４１からクライアント４２に対して、初期セグメントＳ1が送信されることになる。
次に、ステップＳ８２において、判定部４１３は、ヘッダhdr_segnoの値とヘッダhdr_nsegの値が等しいか否かを判定する。いまの場合、ヘッダhdr_segnoには０が設定されており、ヘッダhdr_nsegには、そのユニットを構成する全セグメントの数が記述されているので、両者は等しくない。そこで、ステップＳ８３において、生成部４１７は、ヘッダhdr_segnoの値をインクリメントする。いまの場合、０の値が１に書き換えられる。そして、ステップＳ７７において、生成部４１７は、再びセグメントを生成する処理を実行する。いまの場合、ヘッダhdr_nsegに、そのユニットを構成する全セグメントの数が記述されるとともに（この値は前回のセグメントの場合と同一である）、ヘッダhdr_segnoにセグメント内の順番として１が書き込まれ、ヘッダhdr_lenにデータ長として、そのセグメントのデータ長が格納される。
次に、ステップＳ７８において、ヘッダhdr_segnoの値が０であるか否かが判定部４１３により判定される。いまの場合、ヘッダhdr_segnoには１が設定されているため、０ではない。そこで、ステップＳ８０において、生成部４１７は、ヘッダhdr_typeにDATASEGを指定する。これは、そのセグメントは、データセグメントであることを表す。生成部４１７は、そしてそのセグメントのデータ部（ペイロード）に番号１のセグメントを格納する。ステップＳ８１において、送信部４１５は、以上のようにして生成されたセグメントを、クライアント４２に向けて送信する。
ステップＳ８２において、ヘッダhdr_segnoに記述されているセグメントの連続番号が、ヘッダhdr_nsegに記述されているそのユニットの全セグメントの数に等しいか否かが判定される。いまの場合、セグメントの連続番号は１であり、まだ全セグメントの数に達していないので、ステップＳ８３において、ヘッダhdr_segnoに設定されるセグメントの連続番号が、１から２にインクリメントされる。
以下、順次同様の処理が行われ、ユニットを構成する各セグメントが順次送信される。そして、ステップＳ８２において、ヘッダhdr_segnoに記述されているセグメントの連続番号が、ヘッダhdr_nsegに記述されているそのユニットの全セグメントの数と等しいと判定された場合、そのユニットの送信処理は終了される。すなわち、これにより、再び新たなユニットの要求が受信されたとき、新たなユニットのセグメント単位での伝送が行われることになる。
一方、ステップＳ７５において、ヘッダhdr_uidに記述されているユニットIDのユニットのサイズが、ヘッダhdr_abufに記述されている通知バッファサイズと等しいか、それより大きいと判定された場合、そのユニットのデータをそのままクライアント４２に送信しても、クライアント４２ではデータ量が多すぎて、リアルタイムでこれを処理することができないおそれがある。そこで、この場合には、ステップＳ８４において、選択部４１４は、ステップＳ７３で指定した比較ファイルのビットレートを、一段下げたファイルにする。具体的には、いま、設定されているのが256kbpsでエンコードされたエンコードコンテンツＣ4である場合には、128kbpsでエンコードされたエンコードコンテンツＣ3にそのファイルが変更される。
判定部４１３は、ステップＳ８５において、ステップＳ８４の処理で一段下げられたファイルが存在するか否かを判定部４１３は判定する。そのファイルが存在する場合には、ステップＳ７４において、取得部４１１は、比較ファイルに記述されているファイルのユニットであって、ヘッダhdr_uidに記述されているユニットIDのユニットのサイズを取得する。そして、ステップＳ７５において、ステップＳ７４で取得されたユニットのサイズは、ヘッダhdr_abufの通知バッファサイズ以下か否かが判定される。ユニットのサイズがヘッダhdr_abufの通知バッファサイズと等しいか、それより大きい場合には、再びステップＳ８４において、さらにビットレートを一段下げたファイルに変更される。
このようにして、エンコードコンテンツＣ3，Ｃ2，Ｃ1の順番に、比較ファイルのビットレートが変更される。そして、ステップＳ７５において、いま選択されている比較ファイルのユニットのサイズが、ヘッダhdr_abufの通知バッファサイズ以下であると判定された場合には、ステップＳ７６以降の処理が実行されて、そのユニットのデータがセグメント単位で順次クライアント４２に送信される。
このように、クライアント４２の転送許容量を考慮することで、最大の効率でデータをサーバ４１からクライアント４２に送信することができる。
これに対して、ステップＳ８５において、ファイルが存在しないと判定された場合、すなわち、図７の例において、最もビットレートが低いエンコードコンテンツＣ1においても、ユニットのサイズがヘッダに記述されている通知バッファサイズより大きい場合には、結局、クライアント４２の遅延バッファ３０１の容量が不足しており、サーバ４１は、クライアント４２に対して、そのクライアント４２が連続的に再生可能なストリーミング配信ができないおそれがある（例えば、再生画像が途中で途切れるおそれがある）ことを意味する。そこで、この場合には、ステップＳ８６において、指定部４１２は、ヘッダhdr_typeにBUFLACKを指定する。すなわち、これは、クライアント４２の遅延バッファ３０１の容量が不足していることを表す。そして、ステップＳ８７において、送信部４１５は、セグメントを送信する。この場合においては、コンテンツの実質的なデータはそのセグメントに配置されず、実質的にヘッダだけが送信される。
以上のようにして、図１９に示されるように、初期セグメントＳ1が送信された後、第２のセグメントＳ2、第３のセグメントＳ3などが順次送信される。そして、そのユニットを構成する最後のセグメント（図１９の例の場合、第５番目のセグメントＳ5）が送信されると、そのユニットの送信処理は終了される。
これにより、サーバ４１からクライアント４２に対して、クライアント４２により指定されたユニットが、セグメントに分割されて送信される。
なお、このサーバ４１が、クライアント４２にデータを送信するとき、UDP（User Datagram Protocol）、TCP等のトランスポート層のプロトコルにより、パケットにデータが区分されて送信されることになる。そこで、このセグメントは、１つのパケットに納まるようにそのデータ量が予め設定される、これにより、１個のパケットにより１個のセグメントが送信される結果となり、インターネット６１を介してのデータの送受信が容易となる。
次に、以上のようにして、サーバ４１がクライアント４２に送信したセグメントを受信する処理について説明する。この処理を実行するため、クライアント４２は、図２０に示されるような機能的構成を有している。すなわち、クライアント４２は、判定部３６１、設定部３６２、更新部３６３、格納部３６４、開放部３６５、および一時記憶部３６６を、遅延バッファ３０１以外に有している。なお、この図２０の構成は、図１４の構成と実際には一体化されるものである。
従って、例えば、図１４と図２０の判定部３３２と判定部３６１、設定部３３３と設定部３６２、更新部３３６と更新部３６３、開放部３３８と開放部３６５などは、実際には共通化することが可能である。
判定部３６１は、ヘッダの内容を調べたり、初期セグメントが最初に届いたか否かを判定したり、ユニットが完成したかどうかを判定したりする処理を実行する。設定部３６２は、変数に所定の値を設定する。更新部３６３は、変数やヘッダの内容を更新する。格納部３６４は、データを適宜所定の位置に転送し、格納する処理を実行する。開放部３６５は、予約領域を開放する処理を行う。一時記憶部３６６は、１ユニット分のデータが収集されるまで、データセグメントを一時的に記憶する。
次に、図２１のフローチャートを参照して、クライアント４２のセグメント受信処理について説明する。この処理は、クライアント４２が図１６のユニット要求パケット送信処理を行った後、これに対応してサーバ４１が図１８のユニット要求パケット受信処理を行うので、さらにこれに対応して、クライアント４２により実行される。
ステップＳ１１１において、判定部３６１は、サーバ４１から送信されてきたパケットのヘッダhdr_typeを調べる。そして、その記述がINITSEGである場合には、処理はステップＳ１１２に進み、DATASEGである場合には、処理はステップＳ１１６に進み、BUFLACKである場合には、処理はステップＳ１２５に進む。
また、ステップＳ１１１において、判定部３６１は、ヘッダhdr_uidに記述されているユニットIDを変数ｎに設定し、ヘッダhdr_sidに記述されているサーバIDを、変数ｓに設定する。
ヘッダhdr_typeに記述されているのがINITSEGである場合、すなわち、いま受信されたセグメントが、初期セグメントである場合には、ステップＳ１１２において、判定部３６１は、初期セグメントが最初に届いたか否かを判定する。具体的には、変数ucb_recvに記述されている全受信データ量が０であるか否かが判定される。すなわち、上述したように、初期セグメントは、実質的にコンテンツデータを有していないが、それ以外のセグメントはコンテンツデータを含んでおり、そのデータ量が、後述するステップＳ１１７において、変数ucb_recvに累積加算される。従って、全受信データ量を表す変数ucb_recv の値が０であるということは、初期セグメントが最初に届いた（コンテンツデータを有するセグメントはまだ受信されていない）ということを意味する。この場合には、ステップＳ１１３において、設定部３６２は、変数ucb_sampleに１を設定する。この変数ucb_sampleは、初期セグメントが最初に届いたか否かを表すフラグであるとともに、ユニット受信完了時におけるネットワークの帯域検出のサンプリングの可否を表すフラグであり、この値が１である場合には、後述するステップＳ１２２において、ボトルネックの帯域を表す変数scb_bandを更新する処理が実行され、その値が１ではない場合には、この更新処理はスキップされる。
そこで、ステップＳ１１２において、初期セグメントが最初に届いていないと判定された場合には、ステップＳ１１３における変数ucb_sampleに１を設定する処理はスキップされ、処理はステップＳ１１４に進む。ステップＳ１１３の処理により、変数ucb_sample に１が設定された後、または、ステップＳ１１２において、初期セグメントが最初に届いていないと判定された場合、ステップＳ１１４において、更新部３６３、ヘッダhdr_tstmpと現在時刻からRTTを計算する処理を実行する。すなわち、ヘッダhdr_tstmp には、図１６のステップＳ３４において、そのユニットの要求パケットを送信するときの時刻が、タイムスタンプとして記述されている。従って、図１９に示されるように、ユニット要求パケットを送信したときの時刻と、サーバ４１から初期セグメントを受信した時の時刻（現在時刻）との差から、RTTが計算される。
更新部３６３は、さらに、加重平均により、予測ラウンドトリップタイムを表す変数scb_rtt を更新する。
例えば、ユニット要求パケットを送信した時刻であるヘッダhdr_tstmpに記述されているタイムスタンプの値（内部クロックの値）が1202300ミリ秒であり、初期セグメント到着時刻が、1203400ミリ秒である場合、RTTのサンプルは、1100ミリ秒（＝1203400−1202300）と計算される。このとき、RTTは、次式によって加重平均される。
scb_rtt[s]＝scb_rtt[s]×（1−α）＋1100×α ・・・（５）
ステップＳ１１５において、格納部３６４は、変数ucb_init に現在時刻を格納する。すなわち、変数ucb_initに、初期セグメント受信時刻が記述されることになる。格納部３６４はまた、ヘッダhdr_nsegを変数ucb_nseg に格納する。すなわち、ヘッダhdr_nsegに記述されているそのユニットの全セグメントの数が、変数ucb_nseg に格納される。
変数ucb_nsegには、このようにして、そのユニットの全セグメント数が格納される。
一方、ステップＳ１１１において、ヘッダhdr_typeの値が、DATASEGであると判定された場合、ステップＳ１１６において、更新部３６３は、受信データのセグメント数を更新する処理を実行する。具体的には、全受信セグメント数を表す変数ucb_csegの値が、それまでの値に累積加算される。これにより、変数ucb_csegには、それまでに受信したセグメントの数が格納されることになる。
ステップＳ１１７において、更新部３６３は、全受信データを更新する。具体的には、全受信データ量を表す変数ucb_recvに、ヘッダhdr_lenの値が累積加算される。すなわち、ヘッダhdr_lenには、そのセグメントのデータ長が記述されているので、各セグメントのデータ長の累積和が変数ucb_recvに累積加算されることになる。
ステップＳ１１８において、判定部３６１は、ユニットが完成したか否かを判定する。具体的には、ステップＳ１１５の処理で格納した全セグメント数を表す変数ucb_nsegの値が、ステップＳ１１６の処理で更新された受信データのセグメント数を表す変数ucb_csegの値と等しいか否かが判定される。両者が等しくない場合には、ステップＳ１１９において、格納部３６４は、そのデータセグメントを、一時記憶部３６６に格納する。
この図２１の処理が、セグメントを受信する度に行われるので、一時記憶部３６６には、データセグメントが順次記憶され、１ユニット分のデータセグメントが全て受信されたとき、ステップＳ１１８において、ユニットが完成したと判定される。すなわち、変数ucb_nsegの値が、変数ucb_csegの値と等しくなる。このとき、ステップＳ１２０において、更新部３６３は、ロス率０で加重平均により変数scb_lossを更新する。
例えば、ロス率が０で行われる加重平均は、次のようになる。
scb_loss[ucb_sid[i]]＝scb_loss[ucb_sid[i]]×（1−α）＋0.2×α ・・・（６）
ステップＳ１２１において、判定部３６１は、変数ucb_sampleの値が１か否かを判定する。初期セグメントが最初に届いた場合には、上述したように、ステップＳ１１３において、この変数に１が設定されている。この場合には、ステップＳ１２２において、更新部３６３は、変数ucb_initからの経過時間と、変数ucb_recvにより帯域を計算し、加重平均により変数scb_bandを更新する。
すなわち、変数ucb_init には、ステップＳ１１５の処理で、初期セグメントを受信した時刻が記述されており、その時刻を現在時刻から減算することで、その時点からの経過時間が演算される。また、変数ucb_recvには、ステップＳ１１７の処理で、それまでに受信された全データ量が記述されている。そこで、この変数ucb_recvの値を経過時間で割り算することで、遅延時間当たりのデータ受信量、すなわち、帯域を計算することができる。さらに、これを加重平均することで、ボトルネックリンクの予測帯域幅を表す変数scb_bandの値を更新する処理が実行される。
例えば、変数ucb_init[n]で表される初期セグメント到着時刻が、1203400ミリ秒で、変数ucb_recv[n]で表される受信したセグメントの総バイト数が5670000byteであり、ユニットが完成した時刻である現在時刻が、1205400ミリ秒であるとする。この場合、帯域は、次式により計算される。
5670000／（（1205400−1203400）／1000）＝2835000byte／秒 ・・・（７）
また、変数scb_band[s]の加重平均は、次式により計算される。
scb_band[s]＝scb_band[s]×（1−α）＋2835000×α ・・・（８）
この処理が実行された後、処理はステップＳ１２３に進む。ステップＳ１２１において、変数ucb_sampleが１ではないと判定された場合、すなわち、初期セグメントが最初に届かなかった場合、ステップＳ１２２の処理はスキップされ、処理はステップＳ１２３に進む。
ステップＳ１２３において、開放部３６５は、予約領域を開放する。具体的には、予約済みのバッファサイズを表す変数gcb_rsvbufの値から、予約済みの通知バッファサイズを表す変数ucb_rbufの値が減算される。すなわち、予約された帯域のユニットが全て受信されたので、その分の予約領域が開放される。
次に、ステップＳ１２４において、格納部３６４は、ユニットを一時、バッファから遅延バッファ３０１へ格納する処理を実行する。具体的には、一時記憶部３６６に記憶されているユニットが、遅延バッファ３０１に転送される。そして、現在のバッファサイズを表す変数gcb_curbufの値に、全受信データ量を表す変数ucb_recvの値が累積加算される。すなわち、これにより、図１１に示される値Cuntが更新されることになる。あるいは、データ量Bcurの値が更新されることになる。
ステップＳ１１１で、ヘッダhdr_typeにBUFLACKが記述されていると判定された場合、ステップＳ１２５で、更新部３６３は、バッファ不足情報を更新する。具体的には、変数scb_lackの値が１だけインクリメントされる、このようにして、変数scb_lackには、それまでにそのサーバから受信したセグメントであって、BUFLACKタイプのセグメントの数が記憶される。
この値は、後述する図２４のステップＳ２２４において、サーバを変更するか否かの判定の基準として用いられる。
以上の処理が、セグメントを受信する毎に実行される。送信を要求するコンテンツユニット、セグメントの管理は、すべてクライアント４２により行われる。従って、クライアント４２が、任意の位置に移動し、それまでとは異なるサーバからそれまでのユニットに続くユニットのストリーミング配信を受信することが可能となる。
クライアント４２は、以上のようにして、遅延バッファ３０１にユニット単位で最大10個のユニットを蓄積するように管理し、所定量のデータが蓄積されると、順次その再生処理を実行し、リアルタイム性を実現する。このため、クライアント４２は、例えば図２２に示される機能的構成を有している。この構成も、実際には、図１４および図２０の構成と一体化されるものである。
図２２の例においては、クライアント４２は、判定部３７１、再生部３７２、および停止部３７３を有している。
判定部３７１は、遅延バッファの占有率の判定処理、遅延バッファにデータがなくなったどうかの判定処理、再生の終了が指示されたかどうかの判定処理などを行う。再生部３７２は、遅延バッファ３０１により蓄積が管理されているコンテンツデータの再生処理を行う。停止部３７３は、再生を停止する処理を実行する。
なお、遅延バッファ３０１には、Bmax，Cunt（Bcur），Brsv，Badv等の管理に必要なデータのみを蓄積し、コンテンツデータそのものは、RAM２２３の別の領域に蓄積するようにしてもよいが、説明を簡略化するため、以下においては、コンテンツデータも遅延バッファ３０１に蓄積されているものとする。
次に、図２３のフローチャートを参照して、クライアント４２が実行するユニットの再生処理について説明する。
ステップＳ１５１において、判定部３７１は、遅延バッファの占有率が50％に達したか否かを判定する。遅延バッファの占有率は、図１１における遅延バッファ３０１の最大値Bmaxに対する現在のバッファ量Bcur（Cunt）の割合（Bcur／Bmax）を意味する。
ステップＳ１５１において、遅延バッファ３０１の占有率が50％に達していないと判定された場合、処理はステップＳ１５６に進み、判定部３７１は、再生を終了するか否かを判定する。すなわち、ユーザから、再生の終了が指令されたか否かが判定され、再生の終了が指令されていない場合には、処理はステップＳ１５１に戻り、それ以降の処理が繰り返し実行される。
ステップＳ１５１において、遅延バッファ３０１の占有率が50％に達したと判定された場合、処理はステップＳ１５２に進み、再生部３７２は、遅延バッファ３０１に蓄積されたコンテンツデータをユニット単位で再生する。すなわち、１ユニットは、１GOPで構成されているため、１ユニットのデータがあれば、それを構成する全フレームのデータをデコードすることが可能である。このようにして、再生部３７２により、再生（デコード）されたデータは、入出力インタフェース２２５を介して出力部２２７に出力され、再生画像としてユーザに呈示される。
ステップＳ１５３において、判定部３７１は、遅延バッファにデータがなくなったか否かを判定する。遅延バッファ３０１にデータがなくなっていない場合には、ステップＳ１５４において、判定部３７１は、再生を終了するか否かを判定する。ユーザから再生の終了が指令されていない場合には、ステップＳ１５２に戻り、ステップＳ１５２，Ｓ１５３，Ｓ１５４の処理が繰り返し実行される。
ステップＳ１５３において、遅延バッファ３０１にデータがなくなったと判定された場合、ステップＳ１５５において、停止部３７３は再生を停止させる。
次に、ステップＳ１５６において、判定部３７１は、再生の終了が指示されたか否かを判定する。終了が指示されていなければ、処理はステップＳ１５１に戻り、それ以降の処理が繰り返し実行される。ステップＳ１５６、またはステップＳ１５４において、再生の終了が指示されたと判定された場合、処理は終了される。
以上のようにして、クライアント４２からの要求に応じてサーバ４１はファイルをユニット単位に分割し、さらに、各ユニットをセグメントに分割してクライアント４２に送信する。クライアント４２は、１ファイル分のデータが全て受信される前に、所定の数量のデータが受信された段階で、再生を開始する。このようにして、リアルタイムでストリーミング配信が実現される。
本発明の実施の形態においては、クライアント４２は、プル型方式でサーバ４１からコンテンツデータのストリーミング配信を受ける。クライアント４２は、上述したように、サーバ４１からコンテンツデータのストリーミング配信を受けるのに必要な管理データを自ら管理している。そこで、クライアント４２は、任意の位置に移動した場合にも、それまでに受信していたコンテンツの所定のユニットに続くユニットを他のサーバ４１から受信して、画像を途切れさせることなく、連続して再生することが可能である。このため、クライアント４２は、サーバを選択する必要がある。
次に、このサーバの選択処理について、図２４のフローチャートを参照して説明する。この処理は、上述した図１６と図２１の処理と並行して実行される。
ステップＳ２２１において、クライアント４２の設定部３３３は、１つのサーバを選択する。例えば、図５の例においては、サーバ４１−１乃至４１−３が存在する。設定部３３３は、これらのサーバの中から、ストリーミング配信を希望するコンテンツを有するサーバを１つ選択する。上述したように、この発明においては、各クライアント４２は、どのサーバがどのコンテンツを有しているのかといったサーバを選択するための情報を、予め保持している。上述した式（２）で表されるTFRの値が、既に分っている場合には、その値が最大となるサーバを、ここで選択することも可能である。あるいは、クライアント４２は、サーバ４１が複数ある場合、プルーブパケットをサーバ４１に送信し、その返答からRTTを測定し、RTTの小さなサーバを選択して、ユニット要求パケットを送信するようにしてもよい。
すなわち、各サーバのRTTが既知である場合には、図２５のフローチャートに示されるようにして、１つのサーバを選択することができる。
この場合においては、ステップＳ２５１において、設定部３３３は、ユニット要求をする現在のサーバのサーバIDを、変数ｎに設定する。ステップＳ２５２において、判定部３３２は、scb_rtt[i]＜scb_rtt[n]を満たすサーバIDであるｉが存在するか否かを判定する。すなわち、現在ユニット要求を行っているサーバ以外のサーバの中から、現在のサーバよりRTTが小さいサーバが存在するか否かが判定される。このようなサーバが存在する場合には、ステップＳ２５３において、設定部３３３は、ユニット要求サーバIDに変数ｉを設定する。これにより、ユニット要求が送信されるサーバが、RTTが現在のサーバより小さいサーバに変更される。これにより、ヘッダhdr_typeが、BUFLACKタイプのセグメントを受信する可能性が低くなり、クライアントがより確実にセグメントを受信することが可能となる。
ステップＳ２５２において、現在のサーバよりRTTが小さいサーバが存在しないと判定された場合には、ステップＳ２５３の処理はスキップされる。
以上のようにして、１つのサーバが選択された後、図２４に戻って、ステップＳ２２２において、送信部３３７は、ステップＳ２２１で選択した１つのサーバ４１に対して、ユニット要求パケットを送信する。このユニット要求パケットの送信処理は、実際には、図１６のステップＳ３７における送信処理として行われる。
次に、ステップＳ２２３において、判定部３３２は、サーバからフィードバックがあったか否かを判定する。ステップＳ２２２で、ユニット要求パケットを送信したにも関わらず、サーバ４１から所定の時間が経過しても何のフィードバックもない場合には、そのサーバ４１は、何らかの原因により故障しているか、通信経路上に何らかの障害が存在するなどが予想される。そこで、予め設定してある一定の時間が経過しても、サーバ４１から何のフィードバックもない場合には、ステップＳ２２１において、設定部３３３は、別のサーバを選択する。そして、ステップＳ２２２において、送信部３３７は、その新たに選択されたサーバに、ユニット要求パケットを送信する。ステップＳ２２３において、判定部３３２は、新たにユニット要求パケットを送信したサーバからのフィードバックがあったか否かを判定する。
以上のようにして、何らかのフィードバックがあるサーバが選択される。
サーバから何らかのフィードバックがあった場合には、ステップＳ２２４において、判定部３３２は、バッファ欠乏通知の数が基準値を越えたか否かを判定する。具体的には、上述した図２１のステップＳ１２５で更新された変数scb_lackの値（そのサーバから受信したセグメントのうち、BUFLACKタイプであったセグメントの総数）が、基準値を超えたか否かが判定される。ステップＳ２２４において、バッファ欠乏通知の数（変数scb_lackの値）が、基準値を越えていないと判定された場合には、ステップＳ２２５において、判定部３３２は、終了が指示されたか否かを判定する。ユーザから終了が指示されていなければ、処理はステップＳ２２４に戻り、それ以降の処理が繰り返し実行される。ステップＳ２２４において、バッファ欠乏通知の数が基準値を越えたと判定された場合、処理はステップＳ２２１に戻り、設定部３３３は、再び、新たなサーバを選択する処理を実行する。そして、新たに選択されたサーバに対して、上述した場合と同様に、それ以降の処理が繰り返し実行される。
ステップＳ２２５において、終了が指示されたと判定された場合、サーバ選択処理は終了される。
本発明が提案するプロトコルである３SPは、ネットワークプロトコルの階層におけるトランスポート層とアプリケーション層の中間に位置する。このことは、Real Time Protocol（RTP）と同様である。トランスポート層としては、UDP（User Datagram Protocol）の利用が推奨されるが、TCPを利用することも可能である。この３SPが提供する主な機能は、次の４つである。
（１）遅延バッファリングを考慮したデータ再送要求送信（例えば、図１６のステップＳ３２の処理）
（２）TCPフレンドリを考慮したデータ転送許容量の推定（例えば、図１６のステップＳ３４において、式（２）で演算した値を通知バッファサイズとする処理）
（３）通信品質に基づいたユニット要求パケットの送信（例えば、図２５のステップＳ２５３の処理）
（４）受信側から指定された転送許容量をベースとしたデータ配信（例えば、図１８のステップＳ８４の処理）
次に、シミュレーションの結果について説明する。発明者らは、Frank H. P. Fitzekなどが公開しているMPEG-4のトレースファイル（ MPEG-4 and H. 263 Video Traces for
Network Performance Evaluation. http://www-tkn.ee.tu-berlin.de/research/trace/
simulation.html.）の最初の２分間をシミュレーションのトラフィックデータとして利用した。サーバには、16kbps，64 kbps，256 kbpsのビットレートでエンコードしたデータがユニットに分割され、保持された。２Mbps，10msのリンクを、20本のフローが共用する場合の３通りのシミュレーションが行われた。１つは、20本のTCP（図２６）、１つは、19本のTCPと１本の輻輳制御機能を有しない３SP（図２７）、他の１つは、19本のTCPと１本の輻輳機能を有する３SP（図２８）である。
これらのシミュレーションの結果を表す図２６乃至図２８は、フローの帯域占有量を１秒毎に集計した結果を表している。
これらの図においては、本来、20本のフローの特性曲線が示されるべきであるが、図が複雑になるので、２本のフローのみが示されている。
図２６の曲線Ａ（TCP）と曲線Ｂ（TCP）のフローで示されるように、曲線Ａは、34秒前後において、また、曲線Ｂは、72秒前後において、それぞれ帯域を大きく占有している。従って、TCPは長い時間でみると、各フローが公平に帯域を利用しているが、短い時間でみると、平等のプロトコルではないことがわかる。
これに対して、図２７に示されるように、輻輳制御が行われないと、曲線Ｃ（３SP）は、曲線Ｄ（TCP）より帯域を大きく占有している結果となっている。これは、100kbps（＝2Mbps／20）が公平な帯域であるリンクであるにも関わらず、３SP（曲線Ｃ）が自らの遅延バッファ量に基づいて256 kbpsの最もクオリティが高いデータをいつも受信しているからである。なお、輻輳制御を行わないということは、式（２）のTFRを計算せずに、式（１）の遅延バッファ量の許容量のみをユニット要求パケットに格納することを意味する。
このように、輻輳制御の仕組みを取り入れず、他のフローの存在を考慮しない通信は、そのフローが多くの帯域を占有してしまう危険性がある。
図２８は、輻輳制御を行った曲線Ｅ（３SP）と、曲線Ｆ（TCP）を示している。この図から明らかなように、輻輳制御を行った３SP（曲線Ｅ）は、一時的な過度の帯域占有はあるものの、図２７と比較すると、明らかに利用帯域が少なくなっており、TCP（曲線Ｆ）も帯域を充分利用できていることがわかる。
以上のように、本発明により、連続メディアを配信するサーバが、クライアントとの一切の通信状態を保持する必要のない通信方式が提案される。連続メディアは、ユニットと呼ばれるデータのかたまりに区切られ、ユニットの粒度でクライアントに配信される。クライアントがユニットを取得するタイミングを適切にスケジューリングすることで、ユニットを連続メディアとして再構成することができる。また、クライアントは要求パケットに輻輳情報を含めることで、サーバは、ユニットの粒度でコンテンツのビットレートの最適化を実現することができる。従来のサーバ主体のプッシュ型連続メディア配送モデルとは異なり、本発明のモデルでは、クライアントがコネクションに関する全ての情報を保持しているため、クライアントの状況に合わせてユニットを取得するサーバを柔軟に変更することが可能となる。
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
この記録媒体は、図６と図１０に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（MD（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア１３１，２３１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM１２２，２２２や、記憶部１２８，２２８に含まれるハードディスクなどで構成される。
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
本発明は、コンテンツデータをインターネットを介してパーソナルコンピュータにストリーミング配信する情報処理システムに適用することが可能である。
従来のプッシュ型の情報処理システムを説明する図である。 本発明のプル型の情報処理システムを説明する図である。 クライアントの移動を説明する図である。 クライアントの移動を説明する図である。 本発明を適用した情報処理システムの構成例を示すブロック図である。 図５のサーバの構成例を示すブロック図である マッピング情報を説明する図である GOPを説明する図である GOPの構成例を説明する図である 図５のクライアントの構成例を示すブロック図である 遅延バッファを説明する図である ステータス情報を説明する図である パケットのヘッダ情報を説明する図である クライアントの送信時の機能的構成例を示すブロック図である クライアントの送信タイマ処理を説明するフローチャートである クライアントのユニット要求パケット送信処理を説明するフローチャートである サーバの機能的構成例を示すブロック図である サーバのユニット要求パケット受信処理を説明するフローチャートである ラウンドトリップタイムの計算を説明する図である 受信時のクライアントの機能的構成を示すブロック図である。 クライアントのセグメント受信処理を説明するフローチャートである。 ユニット再生時のクライアントの機能的構成例を示すブロック図である。 クライアントのユニットの再生処理を説明するフローチャートである。 クライアントのサーバ選択処理を説明するフローチャートである。 １つのサーバを選択する処理を説明するフローチャートである。 シミュレーションの結果を示す図である。 シミュレーションの結果を示す図である。 シミュレーションの結果を示す図である。
符号の説明
４０ 情報処理システム， ４１−１乃至４１−３ サーバ， ４２ クライアント， ６１ インターネット， ３０１ 遅延バッファ， ３３１ 計時部， ３３２ 判定部， ３３５ 保存部， ３３６ 更新部， ３３７ 送信部， ３６３ 更新部， ３６４ 格納部， ３６５ 開放部， ３６６ 一時記憶部， ３７２ 再生部， ４１１ 取得部， ４１３ 判定部， ４１５ 送信部

Claims (22)

  1. ネットワークを介して第１の情報処理装置から第２の情報処理装置に情報を提供する情報処理システムにおいて、
    前記第１の情報処理装置は、
    前記第２の情報処理装置から情報の提供の要求を受信する受信手段と、
    提供する前記情報としての１つのファイルを、単独で復号可能な処理単位に分割して、前記第２の情報処理装置に送信する送信手段と
    を備え、
    前記第２の情報処理装置は、
    前記第１の情報処理装置から送信されてきた前記情報を保持する保持手段と、
    前記保持手段に保持された前記情報を管理し、その保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求手段と、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生手段と
    を備えることを特徴とする情報処理システム。
  2. 前記送信手段は、前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を送信し、
    前記第２の情報処理装置は、前記伝送単位で伝送されてきた前記情報を一時的に記憶する一時記憶手段をさらに備え、
    前記保持手段は、前記一時記憶手段に記憶された前記伝送単位が前記処理単位に達したとき、前記一時記憶手段に記憶された前記処理単位の転送を受け、保持する
    ことを特徴とする請求項１に記載の情報処理システム。
  3. 前記処理単位は、ユニットであり、
    前記伝送単位は、セグメントである
    ことを特徴とする請求項２に記載の情報処理システム。
  4. 前記セグメントは、前記ネットワークで伝送の単位として使用されるパケットに収まる大きさである
    ことを特徴とする請求項３に記載の情報処理システム。
  5. ネットワークを介して第１の情報処理装置から第２の情報処理装置に情報を提供する情報処理システムの情報処理方法において、
    前記第１の情報処理装置の情報処理方法は、
    前記第２の情報処理装置から情報の提供の要求を受信する受信ステップと、
    提供する前記情報としての１つのファイルを、単独で復号可能な処理単位に分割して、前記第２の情報処理装置に送信する送信ステップと
    を含み、
    前記第２の情報処理装置の情報処理方法は、
    前記第１の情報処理装置から送信されてきた前記情報を保持する保持ステップと、
    保持された前記情報の保持量に応じて、１つの前記処理単位を構成する続く前記情報の提供を前記第１の情報処理装置に要求する要求ステップと、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップと
    を含むことを特徴とする情報処理方法。
  6. ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置において、
    前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信手段と、
    前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信手段と、
    前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信手段により新たな前記処理単位の要求が受信されたとき、前記送信手段に、新たな前記処理単位を前記伝送単位で伝送させる判定手段と
    を備えることを特徴とする情報処理装置。
  7. 前記処理単位は、ユニットであり、
    前記伝送単位は、セグメントである
    ことを特徴とする請求項６に記載の情報処理装置。
  8. 前記セグメントは、前記ネットワークで伝送の単位として使用されるパケットに収まる大きさである
    ことを特徴とする請求項７に記載の情報処理装置。
  9. 前記送信手段は、前記処理単位の送信の先頭のタイミングで、実質的に前記情報を含まない空の前記セグメントを送信する
    ことを特徴とする請求項７に記載の情報処理装置。
  10. ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置の情報処理方法において、
    前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、
    前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、
    前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップと
    を含むことを特徴とする情報処理方法。
  11. ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置のプログラムであって、
    前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、
    前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、
    前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップと
    を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
  12. ネットワークを介して他の情報処理装置から情報の提供の要求を受け、前記他の情報処理装置に情報を提供する情報処理装置のプログラムであって、
    前記他の情報処理装置から、前記情報としての１つのファイルの、単独で復号可能な処理単位毎の提供の要求を受信する受信ステップと、
    前記処理単位をさらに伝送単位に分割して、前記伝送単位で前記情報を前記他の情報処理装置に送信する送信ステップと、
    前記処理単位を構成する全ての前記伝送単位が送信されたか否かを判定し、前記処理単位を構成する全ての前記伝送単位が送信されたとき、前記処理単位の送信を終了させ、前記受信ステップの処理により新たな前記処理単位の要求が受信されたとき、前記送信ステップの処理に、新たな前記処理単位を前記伝送単位で伝送させる判定ステップと
    をコンピュータに実行させることを特徴とするプログラム。
  13. ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置において、
    前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持手段と、
    前記保持手段に保持されている前記処理単位の保持量を判定する判定手段と、
    前記判定手段による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求手段と、
    前記他の情報処理装置に対する要求を管理する管理手段と、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生手段と
    を備えることを特徴とする情報処理装置。
  14. 前記管理手段は、前記他の情報処理装置の識別情報、前記処理単位の提供を前記他の情報処理装置に要求した時刻、および前記保持手段に保持する予定の保持量を管理する
    ことを特徴とする請求項１３に記載の情報処理装置。
  15. 前記要求手段は、前記保持手段に保持する予定の保持量を前記他の情報処理装置に通知し、
    前記情報処理装置は、前記他の情報処理装置に通知した保持量に基づいて、前記保持手段における前記保持量の予約量を更新する更新手段
    をさらに備えることを特徴とする請求項１４に記載の情報処理装置。
  16. 前記処理単位は、ユニットであり、
    前記伝送単位は、セグメントである
    ことを特徴とする請求項１３に記載の情報処理装置。
  17. 前記セグメントは、前記ネットワークで伝送の単位として使用されるパケットに収まる大きさである
    ことを特徴とする請求項１６に記載の情報処理装置。
  18. 前記処理単位の送信の先頭のタイミングで、実質的に前記情報を含まない空の前記セグメントを受信したとき、前記処理単位の提供を前記他の情報処理装置に要求してから前記処理単位を受信するまでの時間を演算する演算手段を
    さらに備えることを特徴とする請求項１３に記載の情報処理装置。
  19. １つの前記処理単位を構成する全ての前記伝送単位が受信されるまで、前記伝送単位を一時的に保持する一時記憶手段と、
    １つの前記処理単位を構成する全ての前記伝送単位が前記一時記憶手段に記憶されたとき、１つの前記処理単位を構成する全ての前記伝送単位を、前記一時記憶手段から前記保持手段に転送する転送手段と
    をさらに備えることを特徴とする請求項１３に記載の情報処理装置。
  20. ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置の情報処理方法において、
    前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、
    前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、
    前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、
    前記他の情報処理装置に対する要求を管理する管理ステップと、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップと
    を含むことを特徴とする情報処理方法。
  21. ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置のプログラムであって、
    前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、
    前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、
    前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、
    前記他の情報処理装置に対する要求を管理する管理ステップと、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップと
    を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
  22. ネットワークを介して他の情報処理装置に情報の提供を要求し、前記他の情報処理装置から前記情報の提供を受ける情報処理装置のプログラムであって、
    前記他の情報処理装置が、前記情報としての１つのファイルを、単独で復号可能な処理単位に分割し、前記処理単位を、さらに前記ネットワークの伝送単位毎に分割して送信してきた前記情報を、前記処理単位で保持する保持ステップと、
    前記保持ステップの処理により保持されている前記処理単位の保持量を判定する判定ステップと、
    前記判定ステップの処理による判定結果に基づいて、続く前記処理単位の提供を前記他の情報処理装置に要求する要求ステップと、
    前記他の情報処理装置に対する要求を管理する管理ステップと、
    前記ファイルを構成する全ての前記処理単位が受信される前に、前記保持量が予め設定されている基準値より大きくなったとき、前記情報を前記処理単位で再生する再生ステップと
    をコンピュータに実行させることを特徴とするプログラム。
JP2004120716A 2004-04-15 2004-04-15 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム Pending JP2005303927A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004120716A JP2005303927A (ja) 2004-04-15 2004-04-15 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム
US11/090,127 US20050234892A1 (en) 2004-04-15 2005-03-28 Information-processing system, information-processing apparatus, information-recording method, recording medium and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004120716A JP2005303927A (ja) 2004-04-15 2004-04-15 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム

Publications (1)

Publication Number Publication Date
JP2005303927A true JP2005303927A (ja) 2005-10-27

Family

ID=35097523

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004120716A Pending JP2005303927A (ja) 2004-04-15 2004-04-15 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム

Country Status (2)

Country Link
US (1) US20050234892A1 (ja)
JP (1) JP2005303927A (ja)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010057084A (ja) * 2008-08-29 2010-03-11 Canon Inc 映像送信装置、その制御方法、および制御方法を実行するプログラム
WO2011062133A1 (ja) * 2009-11-17 2011-05-26 日本電気株式会社 コンテンツ再生方法、コンテンツ再生装置及びプログラム
JP2013511196A (ja) * 2009-11-13 2013-03-28 サムスン エレクトロニクス カンパニー リミテッド 部分化を利用した適応的なストリーミング方法及びその装置
JP2013110760A (ja) * 2013-02-04 2013-06-06 Canon Inc 映像送信装置、その制御方法、および制御方法を実行するプログラム
JPWO2012011450A1 (ja) * 2010-07-20 2013-09-09 シャープ株式会社 コンテンツ配信装置、コンテンツ再生装置、コンテンツ配信装置の制御方法、および、コンテンツ再生装置の制御方法
JP2014505295A (ja) * 2011-01-04 2014-02-27 トムソン ライセンシング ライブメディアコンテンツを送信する装置及び方法
US9197689B2 (en) 2010-03-19 2015-11-24 Samsung Electronics Co., Ltd. Method and apparatus for adaptively streaming content including plurality of chapters
US9277252B2 (en) 2010-06-04 2016-03-01 Samsung Electronics Co., Ltd. Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content
US9699486B2 (en) 2010-02-23 2017-07-04 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data
US9756364B2 (en) 2009-12-07 2017-09-05 Samsung Electronics Co., Ltd. Streaming method and apparatus operating by inserting other content into main content
US9860573B2 (en) 2009-11-13 2018-01-02 Samsung Electronics Co., Ltd. Method and apparatus for providing and receiving data
US9967598B2 (en) 2009-11-13 2018-05-08 Samsung Electronics Co., Ltd. Adaptive streaming method and apparatus
USRE48360E1 (en) 2009-11-13 2020-12-15 Samsung Electronics Co., Ltd. Method and apparatus for providing trick play service

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090178091A1 (en) * 2008-01-08 2009-07-09 Hiroki Miyamoto Contents distribution method and receiving device
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US9237387B2 (en) 2009-10-06 2016-01-12 Microsoft Technology Licensing, Llc Low latency cacheable media streaming
JP6238255B2 (ja) 2016-05-25 2017-11-29 株式会社Ｎｅｘｐｏｉｎｔ 監視カメラシステムによる監視方法及び動画分割装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10112852A (ja) * 1996-10-04 1998-04-28 Nippon Telegr & Teleph Corp <Ntt> 映像データ伝送装置及び映像データ伝送方法
WO1998038798A1 (en) * 1997-02-26 1998-09-03 Mitsubishi Denki Kabushiki Kaisha Device, system, and method for distributing video data
JP2002064562A (ja) * 2000-06-07 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 通信コネクション確立方法
JP2003143582A (ja) * 2001-11-07 2003-05-16 Nippon Telegr & Teleph Corp <Ntt> ストリーム映像受信制御方法、およびストリーム映像配信システム、およびストリーム映像受信装置
JP2003169040A (ja) * 2001-12-04 2003-06-13 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2003244676A (ja) * 2002-02-19 2003-08-29 Sony Corp 動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム
JP2003319012A (ja) * 2002-04-19 2003-11-07 Matsushita Electric Ind Co Ltd データ受信装置及びデータ配信システム
JP2004007327A (ja) * 2001-06-29 2004-01-08 Matsushita Electric Ind Co Ltd データ再生装置及びデータ中継装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279029B1 (en) * 1993-10-12 2001-08-21 Intel Corporation Server/client architecture and method for multicasting on a computer network
US5928330A (en) * 1996-09-06 1999-07-27 Motorola, Inc. System, device, and method for streaming a multimedia file
US7143177B1 (en) * 1997-03-31 2006-11-28 West Corporation Providing a presentation on a network having a plurality of synchronized media types
US6446192B1 (en) * 1999-06-04 2002-09-03 Embrace Networks, Inc. Remote monitoring and control of equipment over computer networks using a single web interfacing chip
US7213075B2 (en) * 2000-12-15 2007-05-01 International Business Machines Corporation Application server and streaming server streaming multimedia file in a client specific format
WO2002056181A2 (en) * 2001-01-11 2002-07-18 Force Communications Inc Z File switch and switched file system
US20050066048A1 (en) * 2003-08-22 2005-03-24 Bruce Young Web-based music distribution system and method therefor

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10112852A (ja) * 1996-10-04 1998-04-28 Nippon Telegr & Teleph Corp <Ntt> 映像データ伝送装置及び映像データ伝送方法
WO1998038798A1 (en) * 1997-02-26 1998-09-03 Mitsubishi Denki Kabushiki Kaisha Device, system, and method for distributing video data
JP2002064562A (ja) * 2000-06-07 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 通信コネクション確立方法
JP2004007327A (ja) * 2001-06-29 2004-01-08 Matsushita Electric Ind Co Ltd データ再生装置及びデータ中継装置
JP2003143582A (ja) * 2001-11-07 2003-05-16 Nippon Telegr & Teleph Corp <Ntt> ストリーム映像受信制御方法、およびストリーム映像配信システム、およびストリーム映像受信装置
JP2003169040A (ja) * 2001-12-04 2003-06-13 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2003244676A (ja) * 2002-02-19 2003-08-29 Sony Corp 動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム
JP2003319012A (ja) * 2002-04-19 2003-11-07 Matsushita Electric Ind Co Ltd データ受信装置及びデータ配信システム

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010057084A (ja) * 2008-08-29 2010-03-11 Canon Inc 映像送信装置、その制御方法、および制御方法を実行するプログラム
US9860573B2 (en) 2009-11-13 2018-01-02 Samsung Electronics Co., Ltd. Method and apparatus for providing and receiving data
JP2013511196A (ja) * 2009-11-13 2013-03-28 サムスン エレクトロニクス カンパニー リミテッド 部分化を利用した適応的なストリーミング方法及びその装置
USRE48360E1 (en) 2009-11-13 2020-12-15 Samsung Electronics Co., Ltd. Method and apparatus for providing trick play service
US10425666B2 (en) 2009-11-13 2019-09-24 Samsung Electronics Co., Ltd. Method and apparatus for adaptive streaming using segmentation
US9967598B2 (en) 2009-11-13 2018-05-08 Samsung Electronics Co., Ltd. Adaptive streaming method and apparatus
JP2016007026A (ja) * 2009-11-13 2016-01-14 サムスン エレクトロニクス カンパニー リミテッド 部分化を利用した適応的なストリーミング方法及びその装置
WO2011062133A1 (ja) * 2009-11-17 2011-05-26 日本電気株式会社 コンテンツ再生方法、コンテンツ再生装置及びプログラム
US9756364B2 (en) 2009-12-07 2017-09-05 Samsung Electronics Co., Ltd. Streaming method and apparatus operating by inserting other content into main content
US9699486B2 (en) 2010-02-23 2017-07-04 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data
US9197689B2 (en) 2010-03-19 2015-11-24 Samsung Electronics Co., Ltd. Method and apparatus for adaptively streaming content including plurality of chapters
US9277252B2 (en) 2010-06-04 2016-03-01 Samsung Electronics Co., Ltd. Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content
JPWO2012011450A1 (ja) * 2010-07-20 2013-09-09 シャープ株式会社 コンテンツ配信装置、コンテンツ再生装置、コンテンツ配信装置の制御方法、および、コンテンツ再生装置の制御方法
JP2014505295A (ja) * 2011-01-04 2014-02-27 トムソン ライセンシング ライブメディアコンテンツを送信する装置及び方法
US10069887B2 (en) 2011-01-04 2018-09-04 Thomson Licensing Dtv Apparatus and method for transmitting live media content
JP2013110760A (ja) * 2013-02-04 2013-06-06 Canon Inc 映像送信装置、その制御方法、および制御方法を実行するプログラム

Also Published As

Publication number Publication date
US20050234892A1 (en) 2005-10-20

Similar Documents

Publication Publication Date Title
US20050234892A1 (en) Information-processing system, information-processing apparatus, information-recording method, recording medium and computer program
CN111586480B (zh) 低延迟流媒体
Akhshabi et al. An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP
CN105075276B (zh) 在广播通信网络中操作客户端设备和服务器设备的技术
US10110507B2 (en) Push-based transmission of resources and correlated network quality estimation
JP6308718B2 (ja) マルチパス環境におけるアダプティブストリーミングのためのシステムと方法
JP5780684B2 (ja) コンテンツ再生情報推定装置及び方法及びプログラム
US7886071B2 (en) Communication processing device, communication control method, and computer program
KR20120140670A (ko) 병렬 스트리밍
JP7307211B2 (ja) クライアント、サーバ、受信方法及び送信方法
JP2011523298A (ja) クライアント側ストリームスイッチング
TW201026064A (en) Method for audio and video control response and bandwidth adaptation based on network streaming application and server using the same
TWI573450B (zh) 伺服器內所儲存視聽節目表之接收方法和裝置
JP6021385B2 (ja) ストリーミングメディア再生装置、ストリーミングメディア再生方法、及びプログラム
US20090319682A1 (en) Method and device for transmiting data
JP5252347B2 (ja) ネットワークシステム及び通信計画サーバ
WO2022123066A1 (en) Method for playing on a player of a client device a content streamed in a network
JP2011061533A (ja) コンテンツ配信システム、体感品質推定装置、方法、及び、プログラム
US20160050243A1 (en) Methods and devices for transmission of media content
Hayes et al. Adaptive bitrate video delivery using http/2 over mptcp architecture
GB2543840A (en) Method and server for managing the transmission of packets over a plurality of paths
JP6099715B2 (ja) ストリーミングメディア再生装置、ストリーミングメディア再生方法、及びプログラム
Ahsan et al. DASHing towards hollywood
Arthur et al. The effects of packet reordering in a wireless multimedia environment
Laine et al. Network Capacity Estimators Predicting QoE in HTTP Adaptive Streaming

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20051007

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080310

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080317

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080516

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090702

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100121