JP2007057767A - コンテンツ受信装置およびコンテンツ受信方法 - Google Patents

Abstract

【課題】 ポーズ解除時に再生音が途切れることを防止する。
【解決手段】 ポーズが解除されたと判定されると、データの受信が再開され、受信バッファには書き込みのみがなされる。Ｓ２２において、コネクションが切断されないと判定されると、読み出しポインタの手前までデータを受信した場合には、Ｓ２４において、受信バッファからデータを読み出し、再生が再開される。サーバ２からコネクションが切断されたと判定され、Ｓ２５において、曲の最後までデータが受信されたと判定された場合には、受信バッファからデータを読み出し、再生が再開される。最後までデータが受信されないで切断処理がなされたと判定されると、Ｓ２７において、クライアント３はポーズになった位置の情報より再生経過時間を含むパケットのコンテンツデータをサーバ２に要求し、そのデータを受信して再生を再開する。
【選択図】 図７

Description

この発明は、サーバからクライアントに対して音楽コンテンツ等のコンテンツを伝送し、クライアントにおいて、配信された音楽コンテンツを再生することができるコンテンツ受信装置およびコンテンツ受信方法に関する。

ネットワークを介してサーバにあるコンテンツをクライアントが要求し、サーバがそのクライアントに対してコンテンツを送出し、クライアントがコンテンツを再生するコンテンツ配信システムが知られている。例えばホームＬＡＮ(Local Area Network)を設置し、サーバから受信した音楽コンテンツをサーバと離れた部屋のスピーカで再生するシステムを構築することが可能である。このようなコンテンツ配信システムにおいても、メディアの再生プレーヤーと同様に、再生一時停止（ポーズと称する）操作によって再生を一時停止し、ポーズ解除によって一時停止した時点から再生を開始するポーズ機能を備えることが望ましい。例えば特許文献１には、動画配信システムにおいて、ポーズ解除時に乱れのない画像を提供することが記載されている。

特開２００４−２７４６１９号公報

コンテンツ例えば音楽コンテンツをネットワークを介してクライアントに配信するために、ＴＣＰ(Transmission Control Protocol)／ＩＰ(Internet Protocol)と称されるネットワークプロトコルが使用される。このようなシステムでは、以下に述べるように、ポーズを行うようにされている。

クライアントでポーズの指示がなされると、クライアントは、データの受信を停止し、サーバとのコネクションを継続する。データの受信を停止することは、ウインドウサイズを０にする処理である。サーバは、クライアントからのＡＣＫ(Acknowledgement)にセッ
トされるウインドウサイズを受け取る。サーバは、ウインドウサイズを超えるデータを送信することができないので、ウインドウサイズが０にされると、データの送信も停止する。この状態では、受信バッファ内のデータが保持され、Ｄ／Ａコンバータに対しては、継続的にゼロデータが送出される。

次に、クライアントにおけるユーザの操作によって、ポーズが解除されると、ウインドウサイズが０から所定のサイズとされ、データの受信が再開される。受信されたデータがＤ／Ａコンバータに対して送出され、音楽コンテンツの再生が再開される。

従来のＴＣＰを使用するコンテンツ配信システムにおけるポーズの方法では、１回に送受信するデータ量がクライアントと比較してサーバが大きい場合には、ポーズのために、コネクションを継続したままでデータの受信をクライアントが停止すると、サーバ側に未送信のデータが残る。サーバ側のアプリケーションによってコネクションを切断する場合に、サーバがコネクションを切断する前に未送信のデータをクライアントに対して送信しその後、フラグＦＩＮを"1"にしてコネクションを切断する。

サーバ側によるコネクションの切断時に、ポーズ解除によってクライアントがデータを受信再開した場合、未送信データがクライアントが受信してからコネクションが切断される状態が生じる。すなわち、クライアントは、継続してデータが送られてくるので、コネクションが継続しているとみなし、再生を開始する。しかしながら、未送信のデータを受信してからサーバ側によってコネクションの切断がなされるので、停止または再度途切れた箇所からサーバにデータを要求することになる。この時、一旦再生音が途切れる問題があった。

したがって、この発明の目的は、ポーズ動作を正常に行うことが可能なコンテンツ受信装置およびコンテンツ受信方法を提供することにある。

上述した課題を解決するために、この発明は、サーバと接続するための通信部と、
リングバッファの構成とされ、通信部を介してサーバから送信されたコンテンツを受信し、受信したコンテンツを格納する受信バッファと、
受信バッファから読み出されたコンテンツデータを再生するコンテンツ再生部と、 通信部および受信バッファを制御する制御部と、
制御部に対して操作信号を供給する操作部とを備え、
操作部における操作における再生一時停止指示が制御部に与えられることによって、コンテンツデータの受信を停止すると共に、受信バッファから再生部に対するコンテンツデータの出力を停止し、
再生一時停止解除指示が制御部に与えられることによって、コンテンツデータの受信を再開し、受信したコンテンツデータを受信バッファに書き込み、
コンテンツデータの受信を再開した後に、サーバから接続を切断する信号を受信したか否かを判定し、
コンテンツデータの受信を再開した後に、接続を切断する信号を受信した場合に、要求したコンテンツデータを全て受信したか否かを判定し、全て受信できないと判定された場合に、残りのコンテンツデータをサーバに対して要求し、要求したデータを受信し、受信したデータを再生部に出力して再生を再開し、
接続を切断する信号を受信しない場合に、受信バッファに受信したコンテンツデータを所定量書き込んだ後に受信バッファの読み出しを開始し、読み出したデータを再生部に出力して再生を再開するコンテンツ受信装置である。

この発明は、サーバからのコンテンツデータを受信して受信バッファに書き込み、受信バッファからコンテンツデータを読み出して再生部に出力する再生ステップと、
再生ステップにおいて、再生一時停止指示を発生するステップと、
再生一時停止指示によってコンテンツデータの受信を停止すると共に、受信バッファから再生部に対するコンテンツデータの出力を停止する再生一時停止ステップと、
再生一時停止解除指示が制御部に与えられることによって、コンテンツデータの受信を再開し、受信したコンテンツデータを受信バッファに書き込むステップと、
コンテンツデータの受信を再開した後に、サーバから接続を切断する信号を受信したか否かを判定するステップと、
接続を切断する信号を受信した場合に、要求したコンテンツデータを全て受信したか否かを判定し、全て受信できないと判定された場合に、残りのコンテンツデータをサーバに対して要求し、要求したデータを受信し、受信したデータを再生部に出力して再生を再開するステップと、
接続を切断する信号を受信しない場合に、受信バッファに受信したコンテンツデータを所定量書き込んだ後に受信バッファの読み出しを開始し、読み出したデータを再生部に出力して再生を再開するステップとを有するコンテンツ受信方法である。

この発明によれば、リングバッファの構成の受信バッファが再生時に、書き込みが可能な再利用可能領域としてサーバの送信バッファのサイズ以上の領域を確保しておき、再生一時停止解除時に先に受信バッファに書き込みを開始し、書き込みデータ量が送信バッファ以上となってから受信バッファから再生部に対してデータの出力し、再生動作を再開する。また、受信バッファに書き込みを開始した後に、サーバ側から接続を切断する信号を受信した場合には、コンテンツの最後までのデータが受信されているか否かを判定し、最後まで受信されていない場合には、残りのコンテンツデータがサーバから受信されてから再生が再開される。このようにして、未送信データが再生されてから再生が途切れることを防止できる。

以下、この発明の一実施形態について図面を参照して説明する。図１において、参照符号１は、一実施形態によるコンテンツ再生システムを示す。コンテンツ再生システム１は、コンテンツの配信を行うサーバ２とコンテンツを再生するクライアント３とがネットワーク例えばＬＡＮを介して接続された構成とされている。ネットワーク３としては、有線、無線の何れでも良い。この例では、有線ＬＡＮの例であり、通信を中継するスイッチングハブ４が設けられている。例えばホームＬＡＮを介して別々の部屋に設置されているサーバ２とクライアント３とが接続されている。なお、コンテンツとは、視聴できるテキスト、静止画、動画、音楽等の情報全般を意味する。一実施形態は、音楽コンテンツを再生する例である。

ＴＣＰ(Transmission Control Protocol)／ＩＰ(Internet Protocol)と称されるネットワークプロトコルによって、クライアント３がコンテンツデータを受信しながら再生を行うストリーミング再生を行うことが可能とされている。ＴＣＰは、伝送制御プログラムであり、異なるコンピュータで実行されているプロセス相互の間の通信を可能とする。ＩＰは、異なるネットワーク上のコンピュータ同士のデータ伝送を可能にするためのプロトコルであり、受信したＩＰアドレスに基づいて転送情報がたどるべき経路を決めることによって、経路指定を行う。ハードウェアレベルの通信路上では、パケットの形でデータが送受信される。各パケットには、発信元アドレス、転送されるデータ、宛先アドレスが含まれる。

サーバ２は、音楽コンテンツが格納されたコンテンツ格納部２１と、音楽コンテンツに関するコンテンツ情報が格納されたコンテンツ情報格納部２２と、クライアント３との通信を行う通信部２３と、音楽コンテンツの提供サービスを行う音楽コンテンツ提供部２４と、サーバ２の全体の動作を制御するためのシステムコントロール部２５とからなる。通信部２３には、送信用のバッファが備えられている。

コンテンツ格納部２１は、例えばハードディスクに多数の音楽コンテンツが格納されている構成とされている。格納されている音楽コンテンツに関するコンテンツ情報がコンテンツ情報格納部２２に格納されている。コンテンツ情報は、アルバム、アーチスト等の単位で、曲に関連する情報である。

図２は、コンテンツ情報格納部２２に格納されているコンテンツ情報の一例を示す。各音楽コンテンツに対してコンテンツ番号が付与され、各コンテンツに関して、コンテンツの名称、コンテンツタイプ、サンプリング周波数、チャンネル数、ビット数、ＵＲＬ(Uniform Resource Locator)がコンテンツ情報として保持されている。コンテンツタイプは、リニアＰＣＭ、ＭＰ３、ＪＰＥＧ等を表す。サンプリング周波数は、ディジタル音楽信号のサンプリング周波数例えば４８ｋHzを示す。チャンネル数は、ステレオ２チャンネル、マルチチャンネル等を示す。ビット数は、１サンプル当たりのビット数例えば１６ビット、２４ビット等である。ＵＲＬは、そのコンテンツをクライアント３がサーバ２に対してアクセスするためのものである。これらの項目が全て存在している必要はない。他の項目例えば再生時間を設けても良い。

コンテンツ情報は、サーバ２からクライアント３に送信され、クライアント３の再生部３３を設定するために使用される。なお、この一実施形態では、圧縮符号化された音楽コンテンツは、サーバ２において復号され、復号後のリニアＰＣＭ信号としてクライアント３に配信されるようになされている。

図３は、音楽コンテンツ提供部２４によって、コンテンツ格納部２１に格納されている音楽コンテンツがクライアント３に提供される場合の処理の概略を示す。最初に、コンテンツ提供部２４がコンテンツ情報格納部２２から図２に示すようなコンテンツ情報を読み出す。読み出されたコンテンツ情報が通信部２３を介してクライアント３に送信される（
処理Ｉ）。送信されるコンテンツ情報には、ＵＲＬが含まれている。

コンテンツ情報を受信したクライアント３では、コンテンツ情報を参照して再生を希望する音楽コンテンツを指定する。例えばコンテンツ情報がクライアント３の表示部に表示され、所望のコンテンツ情報にカーソルを位置させ、クリックすることで、音楽コンテンツが指定される。クライアント３からは、指定された音楽コンテンツを特定するための情報例えばＵＲＬがサーバ２に対して送信される（処理II）。

音楽コンテンツ提供部２４は、通信部２３を介してクライアント３から受信したＵＲＬによって指定された音楽コンテンツデータをコンテンツ格納部２１から読み出し、読み出されたデータが通信部２３を介してクライアント３に対して送信される（処理III)。クライアント３では、以下に述べる構成を有し、受信した音楽コンテンツデータが再生される。

図１に示すように、クライアントは、サーバ２との通信のための通信部３１を有し、サーバ２から受信した音楽コンテンツデータがリングバッファの構成の受信バッファ３２に格納される。受信バッファ３２から読み出された受信データが再生部３３に供給される。再生部３３は、受信データをアナログ音楽信号へ変換するＤ／Ａコンバータを有する。再生部３３から出力されるアナログ音楽信号がアンプ３４で増幅され、スピーカ３５によって再生される。この一実施形態では、リニアＰＣＭ信号を受信するために、再生部３３がＤ／Ａコンバータの構成とされている。しかしながら、圧縮符号化データが配信されるシステムでは、再生部３３に圧縮符号化のデコーダが設けられる。

通信部３１に、図示しないが、受信バッファ３２とは別に、通信用の受信バッファが設けられている。通信用の受信バッファは、１回の通信で受信するコンテンツデータを格納するためのものである。この例では、サーバが１回の通信で送信するコンテンツデータのデータ量、すなわち、送信バッファのサイズが受信するコンテンツデータのデータ量すなわち、通信用受信バッファのサイズより大きいものとされている。したがって、サーバ２は、送信バッファに格納されたコンテンツデータを複数回に分けてクライアント３に送信する。

クライアント３全体の動作を制御するシステムコントロール部３６が設けられている。また、ユーザのスイッチの操作、リモートコントロール装置による操作、ＧＵＩ(Graphical User Interface)の操作等の操作を受け付けて、操作に対応する信号をシステムコントロール部３６に供給する入力部３７と、受信したコンテンツ情報を表示したり、クライアント３の動作状態を表示したり、ＧＵＩのための画面を表示する表示部３８とが設けられている。システムコントロール部３６は、入力部３７からの操作信号に応じてクライアント３の動作を制御する。すなわち、サーバ２との間の通信、受信した音楽コンテンツデータの再生処理等がシステムコントロール部３６によって制御される。

上述したコンテンツ再生システム１におけるコンテンツ再生動作を説明する。入力部３７における操作に応答してシステムコントロール部３６がコンテンツ情報の送信要求をサーバ２に対して送信し、図３における処理Ｉとして説明したように、サーバ２からコンテンツ情報を受信する。受信されたコンテンツ情報が表示部３８に表示される。

クライアント３では、表示されているコンテンツ情報を参照して再生したい音楽コンテンツを指定する。リモートコントロール装置のキー入力等によって、音楽コンテンツのコンテンツ番号を指定しても良いし、表示されているコンテンツ情報上でカーソルを移動させ、所望の音楽コンテンツの位置で決定操作を行うようにしても良い。

コンテンツが指定されると、再生部３３が指定されたコンテンツを再生することができるように設定されると共に、図３における処理IIとして説明したように、音楽コンテンツを指定する情報例えばＵＲＬがサーバ２に送信される。図３における処理IIIとして説明
したように、サーバ２は、指定された音楽コンテンツデータをコンテンツ格納部２１から読み出してクライアント３に対して送信する。

サーバ２から配信された音楽コンテンツデータがクライアント３によって受信され、受信バッファ３２に書き込まれる。データの再生可能な一定量の書き込みが完了した段階から再生が開始される。クライアント３は、音楽コンテンツデータを受信しながら音楽コンテンツの再生を行う。

図４および図５は、クライアント３の受信バッファ３２を使用して一実施形態の動作を説明するものである。図４および図５において、受信バッファ３２は、書き込みと読み出しとが並行して行うことが可能なリングバッファの構成を有し、矢印で示すように、図面に向かって左端から右端に向かって書き込み位置および読み出し位置が順次変化し、右端
まで書き込み位置および読み出し位置が到達すると、左端に戻るようになされる。

また、書き込みポインタは、書き込みが終了した時点で更新され、次の書き込み開始位置を示す。読み出しポインタが読み出し開始位置を示す。書き込みポインタは、読み出しポインタも読み出し開始位置を示し、書き込みポインタと同様に更新される。さらに、斜
線が施された領域は、受信バッファ３２において、書き込み済みで且つ読み出しが未だされていない領域を示し、斜線が施されていない領域は、上書きすることができる再利用可能な領域である。

図４Ａは、再生時の受信バッファ３２の動作を示す。受信バッファ３２は、再生中では、再生側の読み出しが所定の周期で連続してなされる。受信バッファ３２から読出された音楽コンテンツデータが再生部３３でＤ／Ａ変換され、アナログ音楽信号がアンプ３４を介してスピーカ３５から再生される。受信バッファ３２に対して音楽コンテンツデータを再生するのに必要な量のデータが蓄積された段階から再生が開始される。

一方、サーバ２から受信された音楽コンテンツデータの書き込みが受信バッファ３２の再利用可能な領域に対してなされる。一例として、通信部３１を介して受信される音楽コンテンツデータの速度は、再生部３３に出力されるデータの速度より速いものとされている。したがって、前回の書き込みポインタの位置に所定データ量Ｍａ以上のデータ量を加えた位置に、読み出しポインタが進んだところで、受信データの書き込みを開始し、そして、書き込みポインタの位置が更新される。その後、読み出しポインタが前回の書き込みポインタの位置に所定データ量Ｍａ以上のデータ量を加えた位置に進むまで書き込み動作が待機される。

所定のデータ量Ｍａは、クライアント３の通信用受信バッファのサイズ以上であれば良いが、この発明では、後述するように、ポーズ解除時の再生音の途切れを防止するために、未送信データの受信を完了してから再生を再開するようにされている。したがって、所定のデータ量Ｍａがサーバ２の送信バッファのサイズとされている。

クライアント３は、ユーザの操作に応答して再生動作以外に音楽プレーヤーにおいて可能とされているのと同様に、停止、ポーズ等の動作も可能とされている。以下、再生中のポーズを行う場合の制御について説明する。

クライアント３において、再生動作中にユーザからポーズの指示が発生すると、受信バッファ３２の読み出しが停止され、再生部３３のＤ／Ａコンバータに対してゼロデータが送出される。したがって、スピーカ３５から音が再生されない。また、曲の先頭からポーズになるまでの再生経過時間の情報が保持される。再生経過時間は、曲の先頭から受信バッファ３２から再生部３３に送出されたデータ量と、サンプリング周波数と、チャンネル数と、ビット数から算出される。例えば（１／１０００）秒の桁まで計算される。但し、圧縮データの場合には、圧縮符号化が復号され、復号データが再生部３３のＤ／Ａコンバータに送出されるデータ量を測定する必要がある。次に、サーバ２とのコネクションを継続したまま、サーバ２からのデータの受信を停止する。

また、ポーズに入ると、音楽コンテンツデータの受信が停止される。ＴＣＰにおいては、ウインドウサイズを０にすることによって、データの受信を停止することができる。サーバは、ウインドウサイズを超えるデータを送信することができないので、ウインドウサイズが０にされると、データの送信も停止する。

クライアントにおけるユーザの操作によって、ポーズが解除されると、受信バッファ３２の読み出しが再開され、また、ウインドウサイズが０から所定のサイズとされ、データの受信が可能とされる。読み出されたデータが再生部３３に対して送出され、音楽コンテンツの再生が再開される。

この発明と異なるポーズ解除時の処理を参考のために説明する。この処理では、ポーズ解除時に、先ず、再生部に対して受信バッファからデータを出力する。その結果、読み出しポインタを移動するので、受信バッファに再利用可能領域が形成される。読み出しポインタが前の書き込みポインタに新たな受信データ量分（例えば通信用受信バッファのサイズ）加えた位置まで進んだところで、サーバからの音楽コンテンツデータの受信を再開する。

このような方法は、コネクションが継続している状態では、問題が生じない。しかしながら、サーバ側でコネクションを切断した場合に問題が生じる。ＴＣＰで１回に送受信するデータ量がクライアントに比してサーバの方が大きい場合には、ポーズのために、コネクションを継続したままでデータの受信が停止されると、サーバの送信バッファに未送信データが残る。

サーバ側のアプリケーションによってコネクションを切断する処理は、ＴＣＰのフラグであるＦＩＮを"1"にセットすることによって実行される。サーバ側のコネクションを切
断する処理の際に、未送信データが送信バッファに残っている場合には、送信データを送信してから切断処理がなされる。クライアントにおいてポーズ解除がなされると、サーバの送信バッファに残っている未送信データがクライアントに対して送出されてしまう。クライアントは、継続してデータが送られてくるので、継続しているとみなし、再生を開始してしまう。

次に、未送信データの送信中または送信後に、ＦＩＮが"1"にセットされ、コネクショ
ンが切断される。クライアントは、コネクションが切断された後の音楽コンテンツのデータをサーバに要求する。コネクションが確立され、サーバから要求したデータを受信するまでの期間、再生音が一時的に得られない音切れの問題が生じる。

この発明は、上述したように、未送信データが存在している時にポーズが解除された場合に、音が一時的に途切れる問題を解決するものである。

最初に、図６を参照してポーズ指示がなされた場合の処理をより詳細に説明する。この処理は、クライアント３のシステムコントロール部３６の制御によってなされる。ユーザが入力部３７において再生動作中にポーズを指示すると、ステップＳ１において、ポーズ状態となる。すなわち、データの受信の停止、受信バッファ３２からの読み出しの停止、並びに再生部３３に対してデータ０の送出がなされる。データ０が送出されるために無音状態となる。なお、一実施形態では、音楽コンテンツデータとしてリニアＰＣＭ信号を受信するので、再生部３３では、Ｄ／Ａ変換の処理が行われるので、再生部３３に対応する用語としてＤ／Ａコンバータが使用されている。

データの受信停止は、ＴＣＰのウインドウサイズを０とすることで実行される。このウインドウサイズ０を受信したサーバ２は、ウインドウが開くまで新規のデータを送信することができない。コネクションを維持するために、サーバ２は、クライアント３に対してプローブセグメントを送信する。クライアント３は、プローブセグメントを受信し、次に期待される順序番号と現在のウインドウサイズ（すなわち、０）をサーバ２に対して通知することによってコネクションを維持する。

ステップＳ２では、ポーズ状態が所定時間例えば３０秒経過したか否かが判定される。この判定は、使用していない接続が所定時間以上存在することによる不都合例えばリソースの無駄な使用を回避するためになされる。所定時間経過していないと判定された場合には、ステップＳ３においてサーバ２側からコネクションが切断されたか否かが判定される。コネクションが切断されていないと判定されると、ステップＳ６において、ポーズ解除の指示がされたか否かが判定される。ポーズ解除の指示がされないと判定されると、制御がステップＳ２（所定時間経過したか否かの判定）に戻る。ステップＳ６においてポーズ解除の指示がされたと判定されると、処理Ｓ２０がなされる。

処理Ｓ２０の詳細については、図７を参照して後述する。処理Ｓ２０に入るまでは、サーバ２とのコネクションが切断されていないので、受信バッファ３２がクリアされておらず、また、送信バッファの残りの未送信データが破棄されておらず、未送信データから受信を再開することによって、即座に同じ位置から再開できる。しかしながら、上述したように、ステップＳ６において、ポーズが解除された後に、サーバのアプリケーションによってコネクションが切断されると、音切れの問題が発生する。したがって、処理Ｓ２０では、データの受信を再開してからコネクションが切断されたか否かが判定され、適切な処理が行われる。

ステップＳ２において、所定時間経過したと判定されると、ステップＳ４において、クライアント３がサーバ２とのコネクションを切断する。コネクションが切断されることによって、サーバ２の送信バッファに残っていた未送信のデータが破棄される。そして、ステップＳ５において、受信バッファ３２に保持されているデータをクリアすると共に、Ｄ／Ａコンバータにデータ０を送出を継続する。受信バッファ３２からＤ／Ａコンバータに対して送出したデータ量、サンプリング周波数、チャンネル数、ビット数等から曲の先頭からポーズになった時点までの再生経過時間を計算し、求められた再生経過時間が保持される。ステップＳ３において、サーバ２側からコネクションが切断されたと判定された場合も、ステップＳ５の処理がなされる。

ステップＳ５の処理の後では、ステップＳ８において、ポーズ解除の指示がされたか否かが判定される。ポーズ解除の指示がされたと判定されると、クライアント３はポーズになった位置の情報より再生経過時間を含むパケットのコンテンツデータをサーバ２に要求する。サーバ２は、この再生経過時間から再生可能なパケットを含むコンテンツデータを送信する。

クライアント３がサーバ２からのデータを受信する（ステップＳ１０）。そして、ステップＳ１１において、受信バッファ３２にデータが再生するのに必要な所定量溜まったか否かが判定される。受信バッファ３２に所定量データが溜まったと判定されると、ステップＳ１２において、受信バッファ３２からＤ／Ａコンバータに対してデータの出力が開始される。このように、一時停止した位置からの再生が開始される。

図４、図５および図７を参照して処理Ｓ２０について説明する。ステップＳ６において、ポーズが解除されたと判定されると、ステップＳ２１においてデータの受信が再開される。ポーズ解除の直後の状態を図４Ｂに示す。読み出しは未だ開始されておらず、書き込みのみがなされる。

ステップＳ２２において、サーバ２からフラグＦＩＮ（＝"1"）が受信されたか否か、
すなわち、コネクションが切断されたか否かが判定される。フラグＦＩＮが受信されないと判定されると、ステップＳ２３において、読み出しポインタの手前までデータを受信したか否かが判定される。図４Ｃは、読み出しポインタの手前までデータを受信した状態を示す。

そして、読み出しポインタの手前までデータを受信したと判定されると、ステップＳ２４において、受信バッファ３２からデータを読み出し、Ｄ／Ａコンバータにデータを出力する。したがって、再生音がスピーカ３５から再生され、再生が再開される。ステップＳ２４では、図５Ａに示すように、読み出しがなされ、書き込みポインタと読み出しポインタとの間隔がサーバの送信バッファ以上になるまで書き込みが待機する。読み出されたデータが再生音として出力される。以降は、再生動作と同様に、受信バッファ３２の書き込みおよび読み出しがなされる。

ステップＳ２２において、サーバ２からのフラグＦＩＮ（＝"1"）をクライアント３が
受信したと判定されると、ステップＳ２５において、曲の最後までデータが受信されたか否かが判定される。曲の最後までデータをサーバ２が送信してフラグＦＩＮを送信してコネクションが切断される処理は、正常な切断処理である。一方、曲の最後までデータをサ
ーバ２が送信しないで、コネクションが切断される処理は、異常な切断処理である。一例として、コンテンツ情報の例えば総演奏時間によって分かる曲のデータ量とＤ／Ａコンバータへの送出データ量とを比較することによって、曲の最後までデータが受信されたか否かを判定することができる。

ステップＳ２５において、曲の最後までデータが受信されたと判定されるた場合には、ステップＳ２４に処理が移る。ステップＳ２４は、上述したように、受信バッファ３２からデータを読み出し、読み出されたデータをＤ／Ａコンバータに出力する処理である。

ステップＳ２５において、曲の最後までデータが受信されないで切断処理がなされたと判定されると、ステップＳ２６において、受信バッファ３２がクリアされる。Ｄ／Ａコンバータに対してはゼロデータが出力される。再生経過時間の測定が継続され、測定された再生経過時間が保持される。図５Ｂは、受信バッファ３２がクリアされた状態を示す。書き込みポインタと読み出しポインタとの両者が初期位置に位置している。

ステップＳ２６処理の後では、ステップＳ２７において、クライアント３はポーズになった位置の情報より再生経過時間の算出を行い、その再生時間を再生開始とするコンテンツデータをサーバ２に要求する。サーバ２は、この再生経過時間から再生可能なパケットを含むコンテンツデータを送信する。

クライアント３がサーバ２からのデータを受信する（ステップＳ２８）。そして、ステップＳ２９において、受信バッファ３２にデータが再生するのに必要な所定量溜まったか否かが判定される。受信バッファ３２に所定量データが溜まったと判定されると、ステップＳ３０において、受信バッファ３２からＤ／Ａコンバータに対してデータの出力が開始される。図５Ｃは、ステップＳ３０の再生動作を示す。このように、一時停止した位置からの再生が開始される。

上述したように、クライアント３がポーズ動作を制御することによって、再生中の音楽の再生を一時停止した場合、所定時間以内にポーズを解除することによって同じ位置からの再生を再開することができる。また、音楽の再生を一時停止し、所定時間以上停止した場合で、再生経過時間の情報を保持しているので、同じ位置から再生を再開することができる。また、一時停止が長時間継続したり、サーバ２が他の優先度の高い処理を行うことによって、サーバ２のアプリケーションによってコネクションが切断された場合でも、再生経過時間の情報を保持しているので、同じ位置から再生を再開することができる。さらに、再生経過時間情報をクライアント３側で保持するので、サーバ２の負荷を軽減できる。

さらに、ポーズ解除がされてデータの受信が再開され、先ず、受信バッファの書き込みを行い、サーバ側からコネクションが切断されない場合、読み出しポインタの手前までデータを受信してから読み出しを開始する。また、ポーズ解除がされてデータの受信が再開され、読み出しポインタの手前までデータを受信する前にサーバ側からコネクションが切断される場合、曲の途中か、曲の最後かを判断し、曲の途中であれば、受信バッファ３２をクリアし、サーバ２に対してポーズ解除の位置からのデータを要求し、改めてデータを受信し、受信バッファ３２に所定量以上のデータが溜まった後に、データを読み出して再生を再開する。

したがって、ポーズになった時点で送信バッファに残っている未送信データがポーズ解除によって受信バッファに取り込まれるために、再生が再開され、その後コネクションが切断されるために、再生が停止することに起因する音の一時的中断が発生することを防止することができる。

この発明は、上述したこの発明の実施形態に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えば、ＴＣＰ以外のプロトコルを使用しても良い。

この発明によるコンテンツ配信システムの一実施形態のブロック図である。 コンテンツ情報の一例を示す略線図である。 音楽コンテンツの配信の処理の概要を示すブロック図である。 この発明の一実施形態における受信バッファの書き込みおよび読み出し処理を示す略線図である。 この発明の一実施形態における受信バッファの書き込みおよび読み出し処理を示す略線図である。 この発明の一実施形態においてクライアントがポーズ指示を行った場合の処理の流れを示すフローチャートである。 この発明の一実施形態においてクライアントがポーズ解除指示を行った場合の処理の流れを示すフローチャートである。

符号の説明

１・・・コンテンツ配信システム
２・・・サーバ
３・・・クライアント
２１・・・コンテンツ格納部
２２・・・コンテンツ情報格納部
２３・・・通信部
２４・・・音楽コンテンツ提供部
２５・・・システムコントロール部
３１・・・通信部
３２・・・受信バッファ
３３・・・再生部
３６・・・システムコントロール部

Claims (6)

1. サーバと接続するための通信部と、
   リングバッファの構成とされ、上記通信部を介して上記サーバから送信されたコンテンツを受信し、受信したコンテンツを格納する受信バッファと、
   上記受信バッファから読み出されたコンテンツデータを再生するコンテンツ再生部と、 上記通信部および上記受信バッファを制御する制御部と、
   上記制御部に対して操作信号を供給する操作部とを備え、
   上記操作部における操作における再生一時停止指示が上記制御部に与えられることによって、上記コンテンツデータの受信を停止すると共に、上記受信バッファから上記再生部に対するコンテンツデータの出力を停止し、
   再生一時停止解除指示が上記制御部に与えられることによって、上記コンテンツデータの受信を再開し、受信した上記コンテンツデータを上記受信バッファに書き込み、
   上記コンテンツデータの受信を再開した後に、上記サーバから接続を切断する信号を受信したか否かを判定し、
   上記コンテンツデータの受信を再開した後に、上記接続を切断する信号を受信した場合に、要求したコンテンツデータを全て受信したか否かを判定し、全て受信できないと判定された場合に、残りのコンテンツデータを上記サーバに対して要求し、要求したデータを受信し、受信したデータを上記再生部に出力して再生を再開し、
   上記接続を切断する信号を受信しない場合に、上記受信バッファに受信したコンテンツデータを所定量書き込んだ後に上記受信バッファの読み出しを開始し、読み出したデータを上記再生部に出力して再生を再開するコンテンツ受信装置。
2. 請求項１において、
   上記サーバが上記接続を切断する場合に、上記サーバの送信バッファに残っている未送信のデータを受信するコンテンツ受信装置。
3. 請求項１において、
   上記所定量のデータは、サーバ側の送信バッファのサイズに対応するデータ量以上であって、再生動作時に、上記所定量のデータの書き込み可能な領域が存在するように、上記受信バッファの書き込みおよび読み出しが制御されるコンテンツ受信装置。
4. 請求項１において、
   コンテンツの先頭から上記受信バッファから上記再生部に対して出力されたデータ量が検出され、検出されたデータ量とコンテンツの総データ量とを比較することによって、上記要求したコンテンツデータを全て受信したか否かを判定するコンテンツ受信装置。
5. 請求項１において、
   上記再生一時停止指示動作の継続時間が所定時間以上の場合には、サーバとの接続を切断する処理を行い、
   上記再生一時停止解除動作では、上記再生一時停止指示動作以降の残りのデータを要求し、要求したデータを受信して再生するコンテンツ受信装置。
6. サーバからのコンテンツデータを受信して受信バッファに書き込み、上記受信バッファからコンテンツデータを読み出して再生部に出力する再生ステップと、
   上記再生ステップにおいて、再生一時停止指示を発生するステップと、
   上記再生一時停止指示によって上記コンテンツデータの受信を停止すると共に、上記受信バッファから上記再生部に対するコンテンツデータの出力を停止する再生一時停止ステップと、
   再生一時停止解除指示が上記制御部に与えられることによって、上記コンテンツデータの受信を再開し、受信した上記コンテンツデータを上記受信バッファに書き込むステップと、
   上記コンテンツデータの受信を再開した後に、上記サーバから接続を切断する信号を受信したか否かを判定するステップと、
   上記接続を切断する信号を受信した場合に、要求したコンテンツデータを全て受信したか否かを判定し、全て受信できないと判定された場合に、残りのコンテンツデータを上記サーバに対して要求し、要求したデータを受信し、受信したデータを上記再生部に出力して再生を再開するステップと、
   上記接続を切断する信号を受信しない場合に、上記受信バッファに受信したコンテンツデータを所定量書き込んだ後に上記受信バッファの読み出しを開始し、読み出したデータを上記再生部に出力して再生を再開するステップとを有するコンテンツ受信方法。
   

Images