JP5093328B2 - コンテンツ配信システム - Google Patents

Description

この発明は、音楽、映像などのコンテンツをサーバからクライアントに配信するコンテンツ配信システムに関する。

サーバがクライアントからの要求に応じて、音楽、映像などのコンテンツを有線ＬＡＮ、無線ＬＡＮなどのネットワークを介して配信するコンテンツ配信システムが各種提供されている。この種のコンテンツ配信システムの一例として例えば非特許文献１に記載されたものがある。このコンテンツ配信システムによれば、ユーザは自室に居ながらクライアントを介してサーバに要求を送り、この要求に応じてサーバから提供される音楽を楽しむことができる。

ヤマハ・ミュージックキャスト（登録商標）カタログ ２００３年８月

ところで、上述した従来のコンテンツ配信システムのユーザは、１曲ずつコンテンツの配信を受けることもできるが、例えば１枚のＣＤに録音された全曲といった単位でコンテンツの配信を受けることも可能である。しかし、後者の場合でも、ＣＤの各曲は、各々別個のコンテンツとしてサーバに記憶されている。このため、従来のコンテンツ配信システムでは、サーバから例えばＣＤ１枚分の全曲のコンテンツ配信を行う場合に、サーバからクライアントに１曲目の配信が行われ、クライアントにおいて１曲目の再生が完了し、その旨がクライアントからサーバに通知された時点で、サーバが２曲目の配信を行う、という具合に、サーバ側では、クライアント側での先行するコンテンツの再生完了を待って、後続のコンテンツの配信を行っていた。ここで、再生完了の通知がクライアントからサーバに送られ、サーバからクライアントに後続のコンテンツが配信され、後続のコンテンツの再生がクライアント側において開始されるまでには、ある程度の待ち時間が掛かる。このため、クライアント側では、各曲がこの待ち時間を空けて再生されることとなる。再生される各曲が独立した曲である場合には、このような待ち時間はユーザにとってさほど苦にはならない。しかし、コンテンツ配信システムのユーザが例えばライブ録音されたアルバムの全曲の配信を受けるような場合もある。この種のアルバムでは、曲と曲との合間でも音が発生しており、ＣＤを再生すると、そのような曲間の音も再生される。しかし、コンテンツ配信システムを利用して、このようなアルバムの全曲の配信を受けると、クライアント側において再生される音楽は、曲と曲との間に比較的長い無音期間を持ったものとなり、ＣＤ再生に比べて、どうしても不自然な音楽になってしまう。

この発明は、以上のような事情に鑑みてなされたものであり、クライアントにおいて待ち時間を空けることなく連続的に複数のコンテンツの再生することが可能なコンテンツ配信システムを提供することを目的とする。

上記課題を解決するため、この発明は、サーバと、このサーバにネットワークを介して接続されたクライアントとを具備し、前記サーバは、複数のコンテンツおよび各コンテンツに関するコンテンツ付属情報を記憶する記憶手段と、グループ化された複数のコンテンツの配信要求を前記クライアントから受けた場合に、グループを構成する各コンテンツを前記記憶手段から順次読み出して連続的に前記クライアントに送信する送信手段とを具備し、前記クライアントは、前記サーバからコンテンツおよびコンテンツ付属情報を受信する受信手段と、前記受信手段によって受信されるコンテンツを順次蓄積するバッファと、前記バッファに蓄積されたコンテンツを先に蓄積されたものから順に読み出して再生する再生手段と、前記コンテンツの再生に先立って、当該コンテンツに対応するコンテンツ付属情報に基づく情報を表示する表示手段とを具備し、前記送信手段は、前記記憶手段から第１コンテンツの最後のデータを送信し終えると、前記グループ化された複数のコンテンツにおいて前記第１コンテンツの次のコンテンツである第２コンテンツに関するコンテンツ付属情報を送信し、当該コンテンツ付属情報の送信に続けて、前記第２コンテンツの送信を開始することを特徴とするコンテンツ配信システムを提供する。
かかる発明によれば、グループ化された複数のコンテンツの配信要求があった場合には、それらのコンテンツが連続的にサーバからクライアントに送られるので、クライアント側ではそれらのコンテンツが連続的に再生される。

この発明の第１実施形態であるコンテンツ配信システムの構成を示すブロック図である。 同実施形態の動作を示すシーケンス図である。 同実施形態の動作を示すシーケンス図である。 この発明の第２実施形態において行われるクロスフェード再生を示す図である。 この発明の第２実施形態において行われるクロスフェード再生を示す図である。

以下、図面を参照して、この発明の実施形態について説明する。
＜第１実施形態＞
図１はこの発明の第１実施形態であるコンテンツ配信システムの構成を示すブロック図である。図１において、サーバ１００は、ＬＡＮなどのネットワークを介して、１または複数のクライアント２００と接続されている。サーバ１００は、クライアント２００からの要求に応じて、コンテンツの配信を行う装置である。本実施形態では、映像トラックのストリームデータおよび音声トラックのストリームデータからなるマルチメディア情報のコンテンツがサーバ１００からクライアント２００に送られる。サーバ１００は、各クライアント２００を対象としたコンテンツの配信制御を行うＣＰＵ１０１と、各種のコンテンツを記憶した記憶装置１０２と、クライアント２００宛のコンテンツを一時的に記憶するバッファ１０３と、クライアント２００との間の通信の制御を行うネットワークインタフェース１０４とを有している。

クライアント２００は、ユーザの操作に従ってサーバ１００にコンテンツの配信要求を送り、これに応じてサーバ１００から配信されてくるコンテンツを再生する装置である。このクライアント２００は、ユーザから指示されたコンテンツをサーバ１００から受信するための制御および受信されたコンテンツを再生するための制御を行うＣＰＵ２０１と、キーパッドなどの操作子を備え、それらの操作情報をＣＰＵ２０１に伝える操作部２０２と、ＣＰＵ２０１からの指示に従い、各種の情報を表示する表示装置２０３と、サーバ１００との間の通信の制御を行うネットワークインタフェース２０４と、ネットワークインタフェース２０４を介してサーバ１００から受信されるコンテンツを一時的に記憶するバッファ２０５と、バッファ２０５内のコンテンツを読み出して音楽および映像を再生するＡＶ出力部２０６とを有している。

本実施形態において、配信対象であるコンテンツの指定方法には、コンテンツを１つずつ指定する個別指定方法と、複数のコンテンツからなるグループを指定するグループ指定方法とがある。ユーザは、クライアント２００の操作部２０２を操作することにより、これら２種類の指定方法にうち所望の方法に従って、配信すべきコンテンツをサーバ１００に指示することができる。また、本実施形態では、コンテンツ配信の動作モードとして、個別送信モードと連続送信モードの２種類がある。個別送信モードは、個別指定方法によりコンテンツの指定がなされた場合に選択される動作モードである。この動作モードにおいて、サーバ１００はクライアント２００からの配信要求に応じてコンテンツを１つずつ配信する。一方、連続送信モードは、グループ指定によりコンテンツが指定された場合に選択される動作モードである。この動作モードにおいて、サーバ１００は、クライアント２００から指定されたグループに属する複数のコンテンツを連続的に送信する。グループ指定によりコンテンツの指定が行われる典型例として、ライブ録音されたアルバムが指定される場合が挙げられる。この場合、アルバムを構成する各曲は、各々別個のコンテンツとして、記憶装置１０２に記憶されている。しかしながら、このアルバムを指定した配信要求がクライアント２００からサーバ１００に送られた場合には、このアルバムを構成する各曲のコンテンツが連続的にクライアント２００に送信されるのである。

図２は連続送信モードが選択された場合における本実施形態の第１動作例を示すシーケンス図である。複数のコンテンツからなるグループに関する配信要求がクライアント２００からサーバ１００に送られると（ステップＳ１０１）、サーバ１００のＣＰＵ１０１は、そのグループについての連続送信モードによるコンテンツ配信の動作を開始する。

まず、サーバ１００のＣＰＵ１０１は、配信要求において指定されたグループにおける最初のコンテンツＡのコンテンツ付属情報を記憶装置１０２から読み出し、これをクライアント２００に送る（ステップＳ１０２）。このコンテンツ付属情報は、コンテンツＡにおける音声トラックのストリームデータに付与されているプリ・エンファシスに関する情報、クライアント２００側でのコンテンツＡの映像再生時に表示装置２０３に表示させるべきタイトルなどを情報を含んでいる。クライアント２００のＣＰＵ２０１は、このコンテンツ付属情報を受信すると、このコンテンツ付属情報に含まれているプリ・エンファシスに関する情報に基づき、音楽再生の際のデ・エンファシス量の設定をＡＶ出力部２０６に指示するとともに、コンテンツ付属情報に含まれているタイトルの表示をＡＶ出力部２０６に指示する。

コンテンツ付属情報の送信を終えたサーバ１００のＣＰＵ１０１は、これに続けて、コンテンツＡの送信を開始する（ステップＳ１０３）。クライアント２００のＣＰＵ２０１は、サーバ１００から送られてくるコンテンツＡのデータをバッファ２０５に蓄積する。そして、一定量のデータが蓄積された時点で、ＣＰＵ２０１は、バッファ２０５に蓄積されたコンテンツＡのデータの再生をＡＶ出力部２０６に指示する。これによりＡＶ出力部２０６は、バッファ２０５に蓄積されたコンテンツＡのデータを先に蓄積されたものから順に読み出し、音声および映像として再生する。ＣＰＵ２０１は、バッファ２０５の残量、すなわち、未だ再生されていないデータの量を監視し、この残量を定期的にサーバ１００に通知する（ステップＳ１０４）。サーバ１００のＣＰＵ１０１は、このクライアント２００から通知されるバッファ２０５の残量に基づき、クライアント２００に送られるコンテンツＡの送信速度の制御を行う。

本実施形態では、バッファ２０５の残量が所定量を越えているときにはコンテンツＡの送信速度を下げ、所定量を下回っているときには送信速度を上げる、という帰還制御が行われる。このような帰還制御により、一定の残量がバッファ２０５において維持されるため、例えばネットワークの混雑などの要因により、サーバ１００およびクライアント２００間のデータ伝送に瞬断が生じたとしても、その間、バッファ２０５内に残っているデータがＡＶ出力部２０６に供給され、音楽および映像が途絶えることなく再生される。

サーバ１００のＣＰＵ１０１は、コンテンツＡの最後のデータを送信し終えると（ステップＳ１０５）、クライアント２００により指定されたグループにおけるコンテンツＡの次のコンテンツＢを選択し、このコンテンツＢのコンテンツ付属情報をクライアント２００に送信する（ステップＳ１０６）。そして、ＣＰＵ１０１は、このコンテンツ付属情報の送信に続けて、コンテンツＢのクライアント２００への送信を開始する（ステップＳ１０７）。従来のコンテンツ配信システムでは、サーバは、コンテンツＡの再生完了の通知を待って、後続のコンテンツＢの配信を開始した。これに対し、本実施形態におけるサーバ１００のＣＰＵ１０１は、連続送信モードにおいては、このようなクライアントからの再生完了通知を待つことなく、コンテンツＡに続けてコンテンツＢを送信するのである。

クライアント２００のＣＰＵ２０１は、コンテンツＡの最後のデータを受信すると、それをバッファ２０５に書き込む。次にＣＰＵ２０１は、コンテンツＢのコンテンツ付属情報を受信すると、このコンテンツ付属情報を内蔵のレジスタ（図示略）に格納する。そして、ＣＰＵ２０１は、コンテンツＢのデータの受信が始まると、このデータをコンテンツＡの最後のデータに続けてバッファ２０５に書き込む。その際、ＣＰＵ２０１は、コンテンツＢにおける最初のデータが格納されたバッファ２０５のアドレスを内蔵のポインタ（図示略）に格納する。

コンテンツＢのデータの受信が開始された後も、暫くの間は、再生未了のコンテンツＡのデータがバッファ２０５に残っている。この間、クライアント２００ではコンテンツＡの再生が続くが、ＣＰＵ２０１は、バッファ２０５におけるデータ再生位置（読み出しアドレス）を常時監視し、内蔵のポインタに格納されたコンテンツＢの最初のデータの格納アドレスと比較する。そして、ＣＰＵ２０１は、この監視および比較の結果に基づき、ＡＶ出力部２０６によるコンテンツＢの再生が開始されるのを事前に察知すると、このコンテンツＢの再生に間に合うように、内蔵のレジスタに格納されたコンテンツＢのコンテンツ付属情報に従って、ＡＶ出力部２０６におけるデ・エンファシス量の設定およびタイトルの表示の制御を行う。そして、コンテンツＢの再生が開始されると、ＣＰＵ２０１は、コンテンツＡの再生終了とコンテンツＢの再生開始をサーバ１００に通知する（ステップＳ１０８）。

サーバ１００のＣＰＵ１０１は、やがてコンテンツＢの最後のデータを送信する（ステップＳ１０９）。ここで、コンテンツＢが、クライアントから指定されたグループにおける最後のコンテンツである場合、ＣＰＵ１０１は、最後のコンテンツであるコンテンツＢの送信が終了したことをクライアント２００に通知する（ステップＳ１１０）。

クライアント２００のＣＰＵ２０１は、その後、最後のコンテンツであるコンテンツＢの再生が終了すると、コンテンツＢの再生終了をサーバ１００に通知する（ステップＳ１１１）。サーバ１００のＣＰＵ１０１は、この通知を受け取ることにより、クライアント２００から指定されたグループ内のコンテンツ配信のための全処理を終了する。
以上のように本実施形態によれば、クライアント２００側において、グループを構成する複数のコンテンツを連続的に再生することができる。

図３は本実施形態の第２動作例を示すシーケンス図である。この動作例では、コンテンツＡ、ＢおよびＣからなるグループの配信要求がクライアント２００からサーバ１００に送られ（ステップＳ２０１）、これに応じてコンテンツＡの配信（ステップＳ２０２）が行われ、さらにこれに引き続いて、コンテンツＢの配信（ステップＳ２０３）が開始される。そして、このコンテンツＢの配信開始後、クライアント２００において依然としてコンテンツＡの再生が行われている間に、コンテンツＡの後にコンテンツＢではなくコンテンツＣを再生する旨の変更要求がクライアント２００からサーバ１００に送られている（ステップＳ２０４）。

サーバ１００のＣＰＵ１０１は、この変更要求を受け取ると、コンテンツＢのクリアをクライアント２００に指示する（ステップＳ２０５）。既に第１動作例において説明したように、クライアント２００のＣＰＵ２０１は、コンテンツＢの受信が開始された時点で、コンテンツＢのコンテンツ付属情報を内蔵のレジスタに格納し、バッファ２０５におけるコンテンツＢの最初のデータの格納アドレスを内蔵のポインタに格納している。ＣＰＵ２０１は、コンテンツＢのクリアの指示を受け取ると、レジスタに格納されたコンテンツ付属情報をクリアすると共に、バッファ２０５においてポインタによって指示されたアドレス以降に格納されているコンテンツＢのデータをクリアする。

一方、サーバ１００のＣＰＵ１０１は、コンテンツＢのクリアの指示を送った後、コンテンツＣのコンテンツ付属情報をクライアント２００に送信し（ステップＳ２０６）、これに引き続いて、コンテンツＣのクライアント２００への送信を開始する（ステップＳ２０７）。

クライアント２００のＣＰＵ２０１は、コンテンツＣのコンテンツ付属情報を受信すると、このコンテンツ付属情報を内蔵のレジスタに格納する。そして、ＣＰＵ２０１は、コンテンツＣのデータの受信が始まると、このデータをコンテンツＡの最後のデータに続けてバッファ２０５に書き込む。その際、ＣＰＵ２０１は、コンテンツＣにおける最初のデータが格納されたバッファ２０５のアドレスを内蔵のポインタに格納する。以後の動作は、上記第１動作例と同様である。
このように、クライアント２００では、コンテンツＡに続けてコンテンツＣがバッファ２０５に蓄積されるので、コンテンツＡに続けてコンテンツＣが再生される。

＜第２実施形態＞
本実施形態では、連続送信モードにより複数のコンテンツが連続的にサーバからクライアントに送られる場合に、クライアントにおいて連続したコンテンツのうち音声トラックのストリームデータのクロスフェード再生を行わせるようにしたものである。この音声トラックのみについてのクロスフェード再生を行うため、本実施形態ではバッファ２０５として音声トラック用のものと映像トラック用のものが別々に設けられている。映像トラックのデータの処理は上記第１実施形態と同様なので説明を省略し、以下では音声トラックのデータの処理のみを説明する。

図４は、本実施形態において行われるクロスフェード再生の原理を説明するものである。本実施形態において、コンテンツを構成する音声トラックのストリームデータはＰＣＭデータであり、プリ・エンファシスが施されている。クライアント２００では、コンテンツがネットワークインタフェース２０４により受信された際、その音声トラックのＰＣＭデータについてはデ・エンファシスが施され、バッファに格納される。そして、コンテンツＡの受信およびバッファへの格納が終わり、コンテンツＢの受信が開始されると、バッファ２０５に記憶されているコンテンツＡの最後尾の所定長のデータとコンテンツＢの先頭の所定長のデータとのクロスフェードが行われ、クロスフェード後のデータがバッファに格納される。図４に示す例では、バッファのアドレスＡＤＲｅにコンテンツＡの最後のデータが書き込まれた後、それに続いて順次受信されるコンテンツＢのデータＤｂとアドレスＡＤＲｅ−ΔＡからアドレスＡＤＲｅまでの領域に既に格納されたコンテンツＡのデータＤａとの間で次の演算が行われ、演算結果ＤｘがアドレスＡＤＲｅ−ΔＡ〜アドレスＡＤＲｅまでの領域に順次格納される。
Ｄｘ＝（１−ｒ）Ｄａ＋ｒＤｂ

ここで、ｒは演算結果Ｄｘの書き込みアドレスがアドレスＡＤＲｅ−ΔＡからアドレスＡＤＲｅに進むに従い、０から１まで連続的に変化する。このようにして、受信済みのコンテンツＡの最後尾の所定長の部分と新たに受信されるコンテンツＢの先頭の所定長の部分とがクロスフェードされ、クロスフェード後のデータがバッファ２０５に格納されるのである。書き込みアドレスがＡＤＲｅに到達した後は、受信されるコンテンツＢのデータはクロスフェードされることなくそのままバッファ２０５のアドレスＡＤＲｅよりも後の領域に格納される。

ＡＶ出力部２０６は、このようにしてバッファに格納されたコンテンツＡおよびＢの音声トラックのストリームデータを順次読み出して再生する。その際、コンテンツＡの最後尾所定長の部分に差し掛かると、クロスフェードされたストリームデータがバッファから読み出され、音として出力される。従って、ユーザによって聴取される音楽をコンテンツＡの曲からコンテンツＢの曲に自然に遷移させることができる。

再生曲がコンテンツＡからコンテンツＢに切り換わる際には、画面に表示するタイトルをコンテンツＡのコンテンツ付属情報に含まれていたものからコンテンツＢのコンテンツ付属情報に含まれていたものに切り換える必要がある。この切り換えは、クロスフェード後のデータＤｘの書き込みアドレスが例えばＡＤＲｅ−ΔＡ／２になった時点で行えばよい。

＜第３実施形態＞
本実施形態も、上記第２実施形態と同様、連続送信モードにより複数のコンテンツが連続的にサーバからクライアントに送られる場合に、クライアントにおいて連続したコンテンツのうち音声トラックのストリームデータのクロスフェード再生を行わせるようにしたものである。

図５は、本実施形態において行われるクロスフェード再生の原理を説明するものである。本実施形態では、音声トラックのストリームデータは例えばＭＰ３（ＭＰＥＧ １ ｌａｙｅｒ ３）方式の符号化アルゴリズムによって符号化することにより得られた符号化データである。このため、ストリームデータのバッファへの書き込み時にクロスフェードを行うのは得策ではない。そこで、本実施形態では、コンテンツＡのストリームデータをバッファに書き込んだ後、その最後の書き込みアドレスＡＤＲｅに続く領域にコンテンツＢのストリームデータを書き込み、このコンテンツＢのストリームデータの書き込みを行いながら次のようなクロスフェードを行う。すなわち、バッファ内においてコンテンツＡの書き込み領域とコンテンツＢの書き込み領域との境界を挟んで所定アドレス長ΔＡだけ隔たった第１読み出し位置と第２読み出し位置をコンテンツＡおよびＢの各ストリームデータの読み出し位置とし、これら第１読み出し位置および第２読み出し位置をアドレスＡＤＲｅ−ΔＡおよびアドレスＡＤＲｅから順次先に進めながら、コンテンツＡのストリームデータとコンテンツＢのストリームデータを読み出し、読み出したデータのデコードおよびデ・エンファシスを行った後、それにより得られたコンテンツＡのデータＤａおよびコンテンツＢのデータＤｂに上記式（１）の演算を施し、その結果得られるデータＤｘをＡＶ出力部２０６から音として出力するのである。
本実施形態においても上記第２実施形態と同様な効果が得られる。

１００……サーバ、１０１……ＣＰＵ、１０２……記憶装置、１０３……バッファ、１０４……ネットワークインタフェース、２００……クライアント、２０１……ＣＰＵ、２０２……操作部、２０４……ネットワークインタフェース、２０５……バッファ、２０６……ＡＶ出力部

Claims (4)

1. サーバと、このサーバにネットワークを介して接続されたクライアントとを具備し、
   前記サーバは、
   複数のコンテンツおよび各コンテンツに関するコンテンツ付属情報を記憶する記憶手段と、
   グループ化された複数のコンテンツの配信要求を前記クライアントから受けた場合に、グループを構成する各コンテンツを前記記憶手段から順次読み出して連続的に前記クライアントに送信する送信手段とを具備し、
   前記クライアントは、
   前記サーバからコンテンツおよびコンテンツ付属情報を受信する受信手段と、
   前記受信手段によって受信されるコンテンツを順次蓄積するバッファと、
   前記バッファに蓄積されたコンテンツを先に蓄積されたものから順に読み出して再生する再生手段と、
   前記コンテンツの再生に先立って、当該コンテンツに対応するコンテンツ付属情報に基づく情報を表示する表示手段と
   を具備し、
   前記送信手段は、前記記憶手段から第１コンテンツの最後のデータを送信し終えると、前記グループ化された複数のコンテンツにおいて前記第１コンテンツの次のコンテンツである第２コンテンツに関するコンテンツ付属情報を送信し、当該コンテンツ付属情報の送信に続けて、前記第２コンテンツの送信を開始する
   ことを特徴とするコンテンツ配信システム。
2. 前記サーバは、
   前記送信手段が前記グループ化された複数のコンテンツにおける最後のコンテンツを送信し終えた場合に、当該最後のコンテンツの送信が終了したことを前記クライアントに通知する第１通知手段
   を具備し、
   前記クライアントは、
   前記第１通知手段により通知された前記最後のコンテンツの再生が終了すると、当該最後のコンテンツの再生が終了したことを前記サーバに通知する第２通知手段
   を具備することを特徴とする請求項１に記載のコンテンツ配信システム。
3. 前記再生手段は、前記バッファから読み出されるコンテンツについて対応したコンテンツ付属情報に基づき、音楽再生の差異のデ・エンファシス量を設定してコンテンツの再生処理を行うことを特徴とする請求項１に記載のコンテンツ配信システム。
4. 前記クライアントは、前記サーバから連続的に送信されたコンテンツをクロスフェード再生する手段を具備することを特徴とする請求項１に記載のコンテンツ配信システム。

Images