(57)【要約】【課題】データの送信制御を行って効率的にストリーミングを再生する。【解決手段】データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データを送信するサーバと、符号化されたデータをサーバより受け取って第２のバッファに格納し、第２のバッファより読み出して再生を行うクライアントと、を備えるストリーミングシステムであって、サーバは、クライアントによるデータの再生開始時刻から、第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、第２のバッファより符号化データが読み出されると、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信し、クライアントは、第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データをサーバより受信して格納する。【選択図】図７
2011066611.tif 000002
【特許請求の範囲】
【請求項１】
データを符号化して第１のバッファに格納し、前記第１のバッファに格納されている符号化データを送信するサーバと、符号化された前記データを前記サーバより受け取って第２のバッファに格納し、前記第２のバッファより読み出して再生を行うクライアントと、を備えるストリーミングシステムであって、
前記サーバは、前記クライアントによる前記データの再生開始時刻から、前記第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記第２のバッファより符号化データが読み出されると、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信し、
前記クライアントは、前記第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データを前記サーバより受信して格納することを特徴とするストリーミングシステム。
【請求項２】
前記サーバは、前記クライアントに再生開始時刻を問い合わせ、前記クライアントから再生開始時刻を受け取ることで、前記データの再生開始時刻を特定することを特徴とする請求項１記載のストリーミングシステム。
【請求項３】
前記クライアントは、前記符号化データの受信量が一定値に達すると再生を始め、
前記サーバは、前記符号化データの送信量から前記データの再生開始時刻を特定することを特徴とする請求項１記載のストリーミングシステム。
【請求項４】
前記サーバは、前記第２のバッファからの読み出し速度と同一の速度で前記符号化データを送信することを特徴とする請求項１から３のいずれか１項に記載のストリーミングシステム。
【請求項５】
前記サーバは、前記読み出し時刻から逆算して、前記同種類の符号化データの送信に間に合うように、前記データの符号化を行うことを特徴とする請求項１から４のいずれか１項に記載のストリーミングシステム。
【請求項６】
前記サーバは、フレーム間圧縮にて符号化することを特徴とする請求項１から５のいずれか１項に記載のストリーミングシステム。
【請求項７】
前記サーバは、次に送信される符号化データが前記読み出される符号化データと同種類となるように、前記符号化データを前記クライアントにＧＯＰの倍数分送信しておき、
前記クライアントにて読み出しが始まると、前記読み出しに合わせて前記クライアントに読み出された符号化データと同種類の前記符号化データをフレーム単位で送信することを特徴とする請求項６記載のストリーミングシステム。
【請求項８】
前記第１のバッファは、最大容量となるフレームを１フレーム格納可能な容量であることを特徴とする請求項６又は７に記載のストリーミングシステム。
【請求項９】
前記第２のバッファは、１ＧＯＰ分のデータ容量を格納可能な容量であることを特徴とする請求項６から８のいずれか１項に記載のストリーミングシステム。
【請求項１０】
前記クライアントは、前記第１のバッファからの符号化データの送出速度と同様の読み出し速度にて、前記第２のバッファから符号化データを読み出すことを特徴とする請求項１から９のいずれか１項に記載のストリーミングシステム。
【請求項１１】
データを符号化して第１のバッファに格納し、前記第１のバッファに格納されている符号化データを送信するサーバであって、
クライアントによる前記データの再生開始時刻から、前記クライアントに備えられ前記符号化データを格納する第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記第２のバッファより符号化データが読み出されると、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信することを特徴とするサーバ。
【請求項１２】
前記クライアントに再生開始時刻を問い合わせ、前記クライアントから再生開始時刻を受け取ることで、前記データの再生開始時刻を特定することを特徴とする請求項１０記載のサーバ。
【請求項１３】
前記符号化データの送信量から前記データの再生開始時刻を特定することを特徴とする請求項１０記載のサーバ。
【請求項１４】
前記第２のバッファからの読み出し速度と同一の速度で前記符号化データを送信することを特徴とする請求項１０から１２のいずれか１項に記載のサーバ。
【請求項１５】
前記読み出し時刻から逆算して、前記同種類の符号化データの送信に間に合うように、前記データの符号化を行うことを特徴とする請求項１０から１３のいずれか１項に記載のサーバ。
【請求項１６】
フレーム間圧縮にて符号化することを特徴とする請求項１０から１４のいずれか１項に記載のサーバ。
【請求項１７】
次に送信される符号化データが前記読み出される符号化データと同種類となるように、前記符号化データを前記クライアントにＧＯＰの倍数分送信しておき、
前記クライアントにて読み出しが始まると、前記読み出しに合わせて前記クライアントに読み出された符号化データと同種類の前記符号化データをフレーム単位で送信することを特徴とする請求項１５記載のサーバ。
【請求項１８】
前記第１のバッファは、最大容量となるフレームを１フレーム格納可能な容量であることを特徴とする請求項１５又は１６に記載のサーバ。
【請求項１９】
サーバにより、データを符号化して第１のバッファに格納し、
前記第１のバッファに格納されている符号化データをクライアントに送信し、
前記クライアントでの前記データの再生開始時刻から、前記クライアントに備えられ前記符号化データを格納する第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記クライアントにより、前記第２のバッファより符号化データが読み出されると、
前記サーバにより、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信し、
前記クライアントにより、前記第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データを前記サーバより受信して格納することを特徴とするストリーミングシステムのデータ配信方法。
【請求項２０】
データを符号化して第１のバッファに格納し、
前記第１のバッファに格納されている符号化データを送信し、
クライアントによる前記データの再生開始時刻から、前記クライアントに備えられ前記符号化データを格納する第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記第２のバッファより符号化データが読み出されると、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信することを特徴とするサーバのデータ配信方法。
【請求項２１】
サーバにより、データを符号化して第１のバッファに格納し、
前記第１のバッファに格納されている符号化データをクライアントに送信し、
前記クライアントでの前記データの再生開始時刻から、前記クライアントに備えられ前記符号化データを格納する第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記クライアントにより、前記第２のバッファより符号化データが読み出されると、
前記サーバにより、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信し、
前記クライアントにより、前記第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データを前記サーバより受信して格納することをコンピュータに実行させるプログラム。
【請求項２２】
データを符号化して第１のバッファに格納し、
前記第１のバッファに格納されている符号化データを送信し、
クライアントによる前記データの再生開始時刻から、前記クライアントに備えられ前記符号化データを格納する第２のバッファより読み出される符号化データ及び前記読み出される符号化データの読み出し時刻を特定し、
前記第２のバッファより符号化データが読み出されると、前記符号化データの読み出しに合わせて、同種類の符号化データを前記クライアントに送信することをコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアデータの送受信を行い、前記データの再生を行うストリーミングシステム、サーバ、それらの方法及びプログラムに関する。
【背景技術】
【０００２】
ストリーミングとは、インターネットなどのネットワークを介して、サーバからクライアントへ動画や音声などのマルチメディアデータを送信し、全データを受信しなくとも一部のデータを受信した時点でクライアントに前記データの再生を可能とする技術である。
【０００３】
ストリーミングにおいて送信する動画は、容量を抑えて効率的に配信するためにＭＰＥＧなどの圧縮方式が用いられる。ＭＰＥＧ形式のデータでは、フレーム間圧縮の技術が用いられる。
【０００４】
フレーム間圧縮とは、映像を構成する１コマ毎のフレーム（画像データ）において、前後のフレームとの差分情報を考慮して、異なる部分の差分情報だけを記録することでデータの圧縮を行う技術である。
【０００５】
ＭＰＥＧ形式のフレーム間圧縮を行った動画データにおいては、主に「Ｉピクチャ」「Ｐピクチャ」「Ｂピクチャ」の３種類のデータで構成される。
【０００６】
Ｉピクチャは、１枚のフレームで画像情報を得ることのできる符号化データであり、圧縮率は低いが単体で画像を形成することができる。
【０００７】
一方、Ｐピクチャは、過去のフレームと現在のフレーム間の差分を符号化したデータである。また、Ｂピクチャは、過去及び未来のフレームと、現在のフレームとの差分を符号化したデータである。Ｂピクチャは、復号に前後のフレームを必要とする分、Ｐピクチャより高圧縮なデータとなる。
【０００８】
これらのデータは、圧縮アルゴリズムにより圧縮率が依存することになるが、おおよその情報量の比としては、４：２：１程度で用いられる。また、一般的なＭＰＥＧ形式のデータは、最低１フレームのＩピクチャを含む１５フレームを単位として扱い、この１単位をＧＯＰ（Ｇｒｏｐ  ｏｆ  Ｐｉｃｔｕｒｅ）と呼ぶ。
【０００９】
このようなストリーミングシステムでは、前後のフレームがなければ再生を行えないために、サーバから送出されたストリーミングデータをクライアント側で再生に必要な全フレームを受信するまで一時的に蓄積するバッファを備えている。
【００１０】
図８は、クライアントに備えられるバッファの時間に対するデータ容量を示す模式図である。図において、縦軸にデータ容量、横軸に時間を示している。データ総量が下がっているときにデータが読み出されて復号化が行われている。また、読み出されるデータによって、容量が異なるため、低下するデータ総量も異なる。なお、ここでは簡単のために一瞬で読み出しが行われるよう図示しているが、実際には一瞬で読み出しが行われることはなく、データ容量により読み出し速度が変化するなど様々である。
【００１１】
図８で示すように、サーバ側から送出されるデータ転送量を一定に保ちながら、バッファ上限値近傍に達したところでデータの読み出し及び復号化（再生）が開始される。バッファ上限値は、読み出しが行われても、サーバ側から受け取ったデータを書き込んでいくことでバッファ下限値に達しない十分な値が設定される。
【００１２】
関連する技術として、例えば特許文献１には、クライアントが自身の最大バッファ容量とネットワークの伝送能力から、自身のバッファに蓄積すべきデータの目標量を可変させる技術について開示されている。
【００１３】
また、特許文献１には、バッファ占有量が目標量近傍で遷移するように、バッファからの読み出し量を再生開始時間から算出し、未来のある時点でのバッファ占有量に基づいてサーバからのデータの送信速度制御を行う技術について開示されている。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００２−８４３３９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
ところで、動画データをＭＰＥＧ形式などに符号化を行いながら配信するストリーミング配信においては、データを送出するサーバ側でも符号化したデータを一時蓄積するバッファが備えられる。また、近年では、省エネなどの観点から、小さいバッファ容量で効率的に再生を行うことが求められている。
【００１６】
しかしながら、特許文献１に記載されているようにクライアント側のバッファ読み出し速度と、サーバからのデータの送信速度とを均衡させることは、前述したようにフレーム間圧縮では１フレームのピクチャ種類によりデータ容量も異なるために、符号化時間を考慮すると制御が煩雑になってしまう。
【００１７】
そこで本発明は、上記問題点に鑑みてなされたもので、データの送信制御を行って効率的に再生可能なストリーミングシステム、サーバ、それらの方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
上記課題を解決するため、本発明におけるストリーミングシステムは、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データを送信するサーバと、符号化されたデータをサーバより受け取って第２のバッファに格納し、第２のバッファより読み出して再生を行うクライアントと、を備えるストリーミングシステムであって、サーバは、クライアントによるデータの再生開始時刻から、第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、第２のバッファより符号化データが読み出されると、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信し、クライアントは、第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データをサーバより受信して格納することを特徴とする。
【００１９】
また、本発明におけるサーバは、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データを送信するサーバであって、クライアントによるデータの再生開始時刻から、クライアントに備えられ符号化データを格納する第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、第２のバッファより符号化データが読み出されると、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信することを特徴とする。
【００２０】
また、本発明におけるストリーミングシステムのデータ配信方法は、サーバにより、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データをクライアントに送信し、クライアントでのデータの再生開始時刻から、クライアントに備えられ符号化データを格納する第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、クライアントにより、第２のバッファより符号化データが読み出されると、サーバにより、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信し、クライアントにより、第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データをサーバより受信して格納することを特徴とする。
【００２１】
また、本発明におけるサーバのデータ配信方法は、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データを送信し、クライアントによるデータの再生開始時刻から、クライアントに備えられ符号化データを格納する第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、第２のバッファより符号化データが読み出されると、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信することを特徴とする。
【００２２】
また、本発明におけるプログラムは、サーバにより、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データをクライアントに送信し、クライアントでのデータの再生開始時刻から、クライアントに備えられ符号化データを格納する第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、クライアントにより、第２のバッファより符号化データが読み出されると、サーバにより、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信し、クライアントにより、第２のバッファから符号化データを読み出すと、読み出した符号化データと同種類の符号化データをサーバより受信して格納することをコンピュータに実行させることを特徴とする。
【００２３】
また、本発明におけるプログラムは、データを符号化して第１のバッファに格納し、第１のバッファに格納されている符号化データを送信し、クライアントによるデータの再生開始時刻から、クライアントに備えられ符号化データを格納する第２のバッファより読み出される符号化データ及び読み出される符号化データの読み出し時刻を特定し、第２のバッファより符号化データが読み出されると、符号化データの読み出しに合わせて、同種類の符号化データをクライアントに送信することをコンピュータに実行させることを特徴とする。
【発明の効果】
【００２４】
本発明により、符号化されたデータの送信制御を行うことで、無駄な遅延をさせることなく効率的に再生させることが可能となる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態に係るストリーミングシステムの構成図である。
【図２】本発明の実施形態に係るサーバの構成図である。
【図３】本発明の実施形態に係るクライアントの構成図である。
【図４】本発明の実施形態に係るバッファに格納されるデータの模式図である。
【図５】本発明の実施形態に係るサーバのフローチャート図である。
【図６】本発明の実施形態に係るクライアントのフローチャート図である。
【図７】本発明の実施形態に係るストリーミングシステムのシーケンス図である。
【図８】関連技術におけるバッファ容量の模式図である。
【発明を実施するための形態】
【００２６】
次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。
【００２７】
図１は、本発明の実施形態におけるストリーミングシステムの構成図である。本ストリーミングシステムは、サーバ１００と、ネットワーク３００を介して接続されるクライアント２００と、を有して構成される。
【００２８】
サーバ１００は、カメラなどを用いてリアルタイムで撮影される動画データ、あるいは予め保持している動画データを符号化してクライアント２００へと符号化した動画データを送出する。
【００２９】
クライアント２００は、サーバ１００より符号化された動画データを受け取り、再生に必要なフレーム分蓄積してそれらを復号化及び再生を行う。
【００３０】
図２は、本発明の実施形態におけるサーバ１００の構成図である。サーバ１００は、記憶部１０１と、符号部１０２と、バッファ１０３と、再生時刻算出部１０４と、送受信部１０５と、を有して構成される。
【００３１】
記憶部１０１は、復号化前のリアルタイムに生成される動画データや、あるいは予め生成された符号化前の動画データを格納している。
【００３２】
再生時刻算出部１０４は、送受信部１０５を介してクライアント２００より受け取った再生開始時刻から未来におけるある時刻に再生されるフレームを特定する。また、クライアント２００へのデータ送出開始をトリガとして、そこからの経過時間から再生開始時刻をサーバ１００側で判断するようにしても良い。
【００３３】
ある時刻における再生フレームは、例えば、１ＧＯＰ当たり１５フレームで符号化が行われたとすれば、１フレーム当たりの再生時間は、約３３ｍｓｅｃとなる。また、フレームの再生される順番は、符号化した順番に基づいているために、再生開始時刻及び経過時間から、その時に再生開始フレームから何番目のフレームが再生されているかを特定して求めることができる。
【００３４】
送受信部１０５は、再生時刻算出部１０４において算出した各フレームの再生時刻を参照して、クライアント２００のバッファからの読み出し量に合わせて、同容量だけバッファ１０３より読み出して送出する。具体的には、サーバ１００がクライアント２００のバッファから読み出されるフレームについてのデータベースを保持しておき、クライアント２００のバッファから読み出される１つのフレームのデータ量と同量のデータをバイト単位で送出する。
【００３５】
なお、その際サーバ１００からクライアント２００へのデータ転送に伴う遅延を考慮して、クライアント２００のバッファの容量が常に一定に保たれるように送出することが好ましい。また、クライアント２００の読み出し速度と、送受信部１０５からの送出速度と、が同一となることが好ましい。
【００３６】
符号部１０２は、再生時刻算出部１０４において算出した各フレームの再生時刻を参照して、送受信部１０５より送出されるデータ容量に合わせ、記憶部１０１に格納された動画データをフレーム間圧縮して、バッファ１０３に格納させる。なお、その際、送受信部１０５からのデータ送出に間に合うように動画データを符号化して格納する。
【００３７】
図３は、本発明の実施形態におけるクライアント２００の構成図である。クライアント２００は、送受信部２０１と、バッファ２０２と、復号部２０３と、再生部２０４と、を有して構成される。
【００３８】
送受信部２０１は、送受信部１０５から送出された符号化データを受け取って、バッファ２０２へと格納する。また、動画の再生開始時刻をサーバ１００へと通知する。
【００３９】
復号部２０３は、バッファ２０２に格納された復号化されているデータの復号を行い、再生部２０４へと送出する。
【００４０】
再生部２０４は、復号部２０３で復号されたデータを順次受け取って再生を行う。
【００４１】
なお、復号及び再生は、バッファ２０２に格納されるデータ容量がオーバーフロー、あるいはアンダーフローを起こさないように閾値以上に貯められてから行われる。
【００４２】
また、再生開始時刻は、バッファ２０２が予め必要量のデータを受信しておいて、指定された再生時刻に再生を開始するようにしても良いし、バッファ２０２がデータを受信し始めて、必要量のデータが受信できた時点で開始するようにしても良い。
【００４３】
次に、本発明の実施形態におけるバッファ１０３及びバッファ２０２に格納されるデータ及びそれらの符号、復号化について詳細に説明する。
【００４４】
ＭＰＥＧ形式のフレーム間圧縮を例にとれば、一般的には図４（ａ）に示すように１５フレームを１単位として１ＧＯＰ毎に同種のピクチャが同様の順番で生成される。
【００４５】
図４（ｂ）は、本発明の実施形態におけるバッファ１０３及びバッファ２０２に格納されるフレームの模式図である。
【００４６】
バッファ１０３には、１ＧＯＰ分、すなわち１５フレーム（Ｂピクチャ１〜Ｐピクチャ４）が格納され、バッファ２０２には、バッファ１０３に格納されているフレームの次に再生されるフレーム（Ｂピクチャ１３）が格納される。
【００４７】
すなわち、バッファ２０２には、バッファ１０３から再生のために読み出して復号化されるフレームと同種のフレームが最初に送出されるように格納される。
【００４８】
なお、ここでは簡単のためにバッファ１０３に１５フレームを格納し、バッファ２０２に次の１フレームを格納するよう２ＧＯＰにて説明を行ったが、バッファ１０３から再生のために読み出されるフレームとバッファ２０２から送出されるフレームとが同種となるように、１５の倍数となる数のフレームをバッファ２０２に格納し、その次に再生に用いられるフレーム以降をバッファ１０３に格納するようにしても良い。
【００４９】
バッファ２０２に１フレームのみ格納する場合には、符号化はクライアントへの送出時間に比べて速く行えるため、バッファ２０２の容量は最も容量の大きいＩピクチャが格納できる程度の大きさがあれば問題ない。このときには、Ｐピクチャ、Ｂピクチャは、Ｉピクチャに比べ容量が小さいために、複数同時に格納できることになる。
【００５０】
なお、バッファ１０３から再生のために読み出して復号化されるフレームと同種のフレームが順次送出されるようにして、複数のフレームを再生順に格納しておいても良い。
【００５１】
また、最初の１ＧＯＰ（複数ＧＯＰ）分のデータ送信は、ＧＯＰ単位で送信しておき、再生が開始された後は、再生に合わせてフレーム単位で送信するようにしても良い。
【００５２】
また、例えば、何らかのずれが生じるなどバッファ１０３から送出されるフレームと、バッファ２０２から読み出されるフレームとが異種類になってしまった場合などには、バッファ２０２は、バッファ１０３からの転送速度とバッファ２０２との読み出し速度とが同じになるように読み書きを行うことで常にバッファが一杯となっている状態を保つ。速度を一定にするには、お互いのバッファが予め決められた速度で送出、あるいは読み出しを行ったり、バッファ１０３からの転送速度にバッファ２０２の読み出し速度を依存させるようにすれば良い。
【００５３】
次に、本発明の実施形態における各装置の動作について図面を参照にして詳細に説明する。なお、以降でも１ＧＯＰ当たりのフレーム数は、１５フレームとして説明する。
【００５４】
図５は、本発明の実施形態におけるサーバ１００のフローチャート図である。
【００５５】
記憶部１０１に格納されたリアルタイムで配信されてくる、あるいは予め格納されている動画データを符号化してバッファ１０３に格納する（ステップＳ１１）。なお、符号化するフレーム数については、バッファ２０２の容量に合わせて複数フレームを符号化し、格納しておいても良い。
【００５６】
符号化したデータを送信して（ステップＳ１２）、動画の再生開始時刻を問い合わせる（ステップＳ１３）。このとき、予めデータ受信量をトリガとしてクライアント１００が再生を開始する場合には問い合わせることなく、再生開始時刻を判断することが可能である。なお、このときクライアント１００は、受信したフレーム数が１５の倍数になったときに再生を開始する。また、１ＧＯＰ当たりのフレーム数が異なれば、送信するフレーム数もその倍数となる。
【００５７】
クライアント２００に送信したフレーム数が１５の倍数となっているか否かを判断し（ステップＳ１４）、１５の倍数になるまで符号化したデータを送信する（ステップＳ１５）。なお、送信するフレーム数は、バッファ２０２の容量から判断しても良いし、予め決めておいても良い。また、１ＧＯＰ当たりのフレーム数が異なれば、送信するフレーム数もその倍数となる。
【００５８】
サーバ１００は、再生開始時刻になったか否かを判断して（ステップＳ１６）、再生開始時刻になれば、再生時刻算出部１０４にてクライアント２００がバッファ２０２からフレームを読み出す時刻を算出し（ステップＳ１７）、算出した時刻に合わせてバッファ１０３に格納されているフレームを順次クライアント２００へと送信し、算出した時刻に合わせたデータの符号化及び送信を繰り返す（ステップＳ１８）。
【００５９】
なお、バッファ２０２の容量変動を極力小さくするために、好ましくは、データ送信にかかる遅延時間を考慮して送信を開始し、読み出し速度と送信速度を均衡させると良い。
【００６０】
また、データの符号化においても、符号化に要する時間を考慮して符号化データの送信時間から逆算して符号化を開始する。
【００６１】
図６は、本発明の実施形態におけるクライアント２００のフローチャート図である。
【００６２】
サーバ１００から送出された符号化データを受信してバッファ２０２へと格納する（ステップＳ２１）。
【００６３】
サーバ１００から動画の再生開始時刻が問い合わせられると（ステップＳ２２）、サーバ１００に対して動画の再生開始時刻を通知する（ステップＳ２３）。なお、動画の再生開始時刻は、予め決められた開始時刻を通知しても良いし、開始と同時に通知しても良い。いずれにしても、バッファ２０２に格納されるフレーム数が１５の倍数となってから再生は開始される。
【００６４】
再生（復号化）を開始して（ステップＳ２４）、バッファ２０２からフレームを読み出して復号化すると略同時にサーバ１００より送出される符号化データを書き込んで順次再生を行っていく（ステップＳ２５）。
【００６５】
図７は、本発明の実施形態におけるストリーミングシステムのシーケンス図である。
【００６６】
サーバ１００は、記憶部１０１に格納されたリアルタイムで配信されてくる、あるいは予め格納されている動画データを符号化してバッファ１０３に格納する（ステップＳ３１）。
【００６７】
符号化したデータをクライアント２００に送信して（ステップＳ３２）、動画の再生開始時刻を問い合わせる（ステップＳ３３）。
【００６８】
クライアント２００は、サーバ１００より送信されたデータを受信してバッファ２０２に格納し（ステップＳ３４）、符号化動画の再生開始時刻をサーバ１００へと通知する（ステップＳ３５）。
【００６９】
サーバ１００は、クライアント２００に送信したフレーム数が１５の倍数となっているか否かを判断し（ステップＳ３６）、１５の倍数になるまで符号化したデータを送信する。なお、送信するフレーム数は、バッファ２０２の容量から判断しても良いし、予め決めておいても良い。このときバッファ２０２の容量は、サーバ１００とクライアント２００の接続時などにクライアント側からサーバ側へと通知される。また、１ＧＯＰ当たりのフレーム数が異なれば、送信するフレーム数もその倍数となる。
【００７０】
サーバ１００は、再生開始時刻になったか否かを判断して（ステップＳ３７）、クライアント２００が再生（復号化）を開始すると（ステップＳ３８）、サーバ１００は、再生時刻算出部１０４にてクライアント２００がバッファ２０２からフレームを読み出す時刻を算出し（ステップＳ３９）、算出した時刻に合わせてバッファ１０３に格納されているフレームを順次クライアント２００へと送信し、算出した時刻に合わせたデータの符号化及び送信を繰り返す（ステップＳ４０）。
【００７１】
このように、本発明の実施形態によれば、クライアントのバッファからの読み出し時間を考慮して、クライアント側のバッファから読み出したデータと同容量のデータを、サーバ側からクライアントのバッファからの読み出し時間に合わせて送出することで、クライアント側のバッファ容量を一定量に保つことが可能となる。
【００７２】
また、その際にＧＯＰを考慮して、クライアントのバッファからの読み出しフレームと同種類のフレームをサーバ側から送出するようにすることによって、サーバ側のバッファでは、最大容量となるフレーム１つ分の容量があれば、一定周期にて符号化及びデータ送信を行うことができ、複雑な演算を必要としなくなる。なお、バッファ１０１の容量は、サーバで設定される１つのＩピクチャの最大値と、一つのＰピクチャの最大値を収容可能な容量とすることで、遅延を最小限に抑え効率的な配信が可能となる。
【００７３】
なお、本発明の実施形態においては、ＭＰＥＧ形式を基にして説明を行ったが、特にＭＰＥＧ形式のみに限定されることなく適用することが可能である。
【００７４】
以上、実施の形態を説明したが、特許請求の範囲に定義された本発明の広範囲な趣旨および範囲から逸脱することなく、これら実施の形態や具体例に様々な修正および変更が可能である。
【符号の説明】
【００７５】
１００    サーバ
１０１    記憶部
１０２    符号部
１０３    バッファ
１０４    再生時刻算出部
１０５    送受信部
２００    クライアント
２０１    送受信部
２０２    バッファ
２０３    復号部
２０４    再生部
３００    ネットワーク
【図１】
2011066611.tif 000003
【図２】
2011066611.tif 000004
【図３】
2011066611.tif 000005
【図４】
2011066611.tif 000006
【図５】
2011066611.tif 000007
【図６】
2011066611.tif 000008
【図７】
2011066611.tif 000009
【図８】
2011066611.tif 000010