JP4526294B2 - ストリームデータ送信装置、受信装置、プログラムを記録した記録媒体、およびシステム - Google Patents

Description

本発明はビデオオンデマンドの様な映像と音声のリアルタイム転送を行うストリームデータ送信装置、ストリームデータ受信装置およびそれらの処理をコンピュータに実行させるための処理プログラムを記録した記録媒体の構成に関わる。

従来の技術として、通信回線の伝送速度に合わせた符号化レートでコンテンツをリアルタイムで転送するシステムが存在した。この場合には回線速度が遅い場合には、たとえコンテンツのデータを記録して保存しても後で視聴することができるのは低品位のコンテンツでしかなかった。

他方、回線の速度に関わらず、高い符号化レートでコンテンツの転送を行ない、受信側では一旦これらのデータを記録して蓄積して、転送が終了した後で高品位のコンテンツとして試聴するシステムが存在したが、回線速度が遅い場合にはこのコンテンツをリアルタイムに試聴することは出来なかった。

これらの問題に対してリアルタイム視聴を可能にし、且つ、後からの高品位なコンテンツの視聴を可能にするための技術が、特許文献１（特開平７−２８８５１０号公報「映像音声伝送システム」）に開示されている。

この特許文献１に開示された方法によれば、送信側では、符号化レートが可変である符号化装置を用いて、コンテンツを符号化レートの低いリアルタイム視聴のためのデータと符号化レートの高い蓄積データのためのデータの双方を生成し、これらを多重化して同時に送信する。受信側では、符号化レートが可変である復号化装置を用いてそれぞれを復号化し、リアルタイム視聴を行ないながら、符号化レートの高いデータを蓄積して、データ転送終了後には高品位のコンテンツの視聴も可能になるというシステムである。

送受信は、２種類のデータを同時に送るために送信側と受信側との間でセッションを２つ張り、これらのデータの送受信を同時に行なう方法である。リアルタイムで試聴するためのデータは帯域を優先して通信回線使用する必要があり、蓄積データはリアルタイムデータで使用される帯域の隙間を利用して送受信される。受信側では高品位のデータのみを記録して蓄積して、高品位データが全て送信終了後に高品位のコンテンツの視聴が可能となる。

この方法の場合には、高品位視聴を可能にする蓄積データはリアルタイムで送受信されるデータとは符号化レートが別であるためにコンテンツのデータとしてはリアルタイムで送受信されるデータと高品位のデータとは独立して別物であり、全体の転送データサイズは高品位データのサイズと低品位のデータのサイズを合わせたサイズが必要となる。

また、リアルタイムの送受信のために帯域を優先して使用する必要があるために、高品位のデータを伝送するために使える帯域は少なくなり全てのデータを受信するまでに時間がかかる。

一方、画質劣化を抑制した間引き処理をして映像データを送信するシステムとして、特許文献２（特開２００２−１３５７６８号公報）に開示された技術がある。このシステムよって、データを間引くことによってデータ伝送量を抑えた映像データの送受信は可能になるが、間引き処理される前の映像データそのものを受け取ることはできないため、送信側のオリジナル映像とまったく変わらない質のデータを受信、蓄積して、表示することはできない。

さらに、従来技術の１つとして、ネットワークの負荷を監視して、負荷に応じてフレームを間引いたデータ量の少ない映像データを送信する技術がある（たとえば、特許文献３を参照）。リアルタイムにネットワークの状況に応じて視聴可能な間引いた映像データを送受信することができるが、ネットワーク負荷の高いときに受信した映像データでは、その時点でリアルタイム視聴可能な画質的には低品質のものしか受信できず、本来の品質の映像データを受信することはできない。
特開平７−２８８５１０号公報 「映像音声伝送システム」 特開２００２−１３５７６８号公報 「データ受信装置、データ送受信システム」 国際公開ＷＯ９８／３８７９８号パンフレット 「ビデオデータ配信装置、ビデオデータ配信システム、並びに、そのビデオデータ配信方法」

本発明は、上記のような問題点を解決するためになされたものであって、その目的は、使用する通信回線の伝送帯域確保が出来ないために、リアルタイムに高品位な品質で視聴する事が出来ないコンテンツに対して、高品位ではないがリアルタイムの視聴を可能にし、かつ、後から同じコンテンツを高品位に視聴することが可能なストリームデータ送信装置、ストリームデータ受信装置およびそれらの処理をコンピュータに実行させるための処理プログラムを記録した記録媒体を提供することである。

すなわち、本発明は、高品質ではあるがデータ転送量の多くなる送受信方法とデータ量は少ないが映像としては低品位となってしまう送受信方法の双方に関わるもので、通信回線の伝送帯域が確保できないためにリアルタイムで高品位の視聴が出来ない場合に回線の帯域をより有効に使用してこれらの問題に対応するものである。

本発明によるストリームデータ送信装置では、高品位視聴が可能なデータの中から、通信回線の伝送速度に合わせてリアルタイムで視聴する事が可能なデータを抜き出してリアルタイム転送を行ない、リアルタイム視聴が終了した時点で、リアルタイム転送時に送受信しなかったデータを送り、ストリームデータ受信装置側では全ての受信データを記録して蓄積しておき、高品位のデータが揃った時点でデータを再構築し治すことで、後から視聴する時には高品位の視聴を可能にする。

上記のような課題を解決するために、本発明のある局面では、ストリームデータの配信を行なうシステムにおけるストリームデータ送信装置であって、ストリームデータを指定した間隔で間引いて選択するデータ選択処理手段と、送信するストリームデータを間引き選択による選択データと非選択データとに分けて管理する送信データ管理手段とを備え、送信データ管理手段の内容に基づき、間引き選択による選択データをリアルタイム送信した後、非選択だった未送信データを送信する。

好ましくは、データ選択処理手段においてデータを間引くための間隔は、通信回線の通信速度とデータをリアルタイムに伝送するのに必要な速度との関係に基づいて決定される。

好ましくは、ストリームデータ送信装置は、あらかじめエンコードされたストリームデータを格納しておくデータ蓄積手段をさらに備え、ストリーミングデータを受信する装置からの要求に応じてデータ蓄積手段が保持するストリームデータの任意の位置からの送信を行なう。

好ましくは、ストリームデータ送信装置は、あらかじめエンコードされたストリームデータを格納しておくデータ蓄積手段をさらに備え、ストリーミングデータを受信する装置からの要求に応じてデータ蓄積手段が保持するストリームデータの任意の位置からの早送り再生や巻き戻し送信を行う。

好ましくは、ストリームデータ送信装置において、通信中における通信路の通信性能の変化に 対応して、ストリームデータの間引きの条件を変化させる。

この発明の他の局面では、ストリームデータ送信装置の処理をコンピュータに実行させるための処理プログラムを記録した記録媒体である。

この発明のさらに他の局面では、ストリームデータの配信を行なうシステムにおけるストリームデータ受信装置であって、受信データを保存するデータ蓄積手段と、リアルタイムに受信するデータとリアルタイム受信後に受信する同一コンテンツのデータから元のストリームデータを再構築する蓄積データ再構築処理手段とを備える。

好ましくは、ストリームデータ受信装置は、リアルタイムに受信するデータを再生しながら該データをデータ蓄積部に保存する。

この発明のさらに他の局面では、ストリームデータ受信装置の処理をコンピュータに実行させるための処理プログラムを記録した記録媒体である。

以下に、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがってそれらについての詳細な説明は繰返さない。

また、以下では、データの例としてＭＰＥＧ（Moving Picture Experts Group）に基づいたものを取り上げて説明しているが、これに限定されるものではない。

図１は、通信回線の伝送速度が十分確保されている場合の送受信を示す摸式図であり、たとえば、２時間のコンテンツ全体を２時間で送受信できる場合である。

この図１で、横軸は時間を表し矩形の中の１、２、３…の番号はストリームデータの順番に対応して付けたシーケンス識別番号５０１である。

この場合には受信側ではリアルタイムで高品位にコンテンツを試聴することが可能である。受信したデータをそのまま記録して蓄積すれば、後からでも高品位のコンテンツを試聴することが可能である。

送信側の装置は、ストリーミング配信するデータに対し、シーケンス識別番号を映像データの先頭に所定のデータサイズで付加したデータを送信データとして送信し、受信側の装置は、受信したデータの先頭からこれから受信する映像データのシーケンス識別番号を読み取ることができる。

具体的には、ＭＰＥＧデータの場合、各フレームに相当するピクチャデータ単位で送信するので、データを蓄積する記憶手段から読み出したピクチャデータに対しシーケンス識別情報として、シーケンシャルにインクリメンタルする数値を含むシーケンス識別情報を付けたデータを送信データとして作成し、リアルタイム視聴可能な範囲でデータを一部間引いて送信する。

間引かれてために送信されなかったデータは一時的に蓄積しておき、リアルタイム視聴完了後に送信する。この送信はリアルタイム送信を行なったセッションで引き続き、送信する実施形態もあるし、また別のセッションとして送信依頼があるまで待ってから送信することも可能である。後者の場合は、リアルタイム送信した際のセッション識別子をシーケンス識別情報に含めることによって、受信側でどのセッションで受信したデータを補完するデータなのかを識別することができる。

受信側の装置は、リアルタイム視聴するためには受信したデータに含まれるピクチャデータのみを用いてデコード、出力する。一方、蓄積する際には、シーケンス識別情報を確認して、完全なデータとして整列したデータを蓄積データとする。

なお、本実施の形態の説明において、ストリーミングは送信側のＨＤＤ（Hard Disc Drive）などに記録されたビデオコンテンツデータをストリーミングする場合を例にとって説明しているが、本発明は、それに限定されるものではない。たとえば、ライブ放送などライブ映像を取り込んで配信するようなサーバにおいても、現実にはバッファリングを行なってエンコードし、送信するのが普通なので、その際に同様に通信帯域に見合うようにデータを一部間引いて送信してライブ視聴することを可能にし、ライブ放送終了後に蓄積用に間引かれたデータを配信することで受信側は完全な高画質データとして蓄積することが可能である。

図２は、通信回線の伝送帯域が半分しか確保できない通信回線を使用して受信する場合を説明するための模式図である。

図２では、リアルタイム視聴に必要な半分の帯域しかない通信回線でコンテンツデータ全体を送受するのに倍の時間を要することを示している
図１で説明したコンテンツに対して、通信回線の伝送帯域が半分しか確保できない通信回線を使用して受信する場合には、図２のように全体のコンテンツの受信に４時間かかってしまう。

この場合にはリアルタイムの視聴を行なうことは出来ない。仮にコンテンツをこの状態でリアルタイムで視聴すればコンテンツはスローモーションでしか試聴できない。

図３は、図２の通信回線を用いて、リアルタイムにコンテンツを視聴する場合を説明するための模式図である。

この通信回線を用いて、リアルタイムにコンテンツを視聴したいのであれば、図３のように、１、３、５…と高品位のデータを間引いた品質の劣る低品位映像で見なければならない。この場合、これら１、３、５の受信したデータを蓄積して後で再度見る場合でも低品位のコンテンツしか視聴出来ない。

図４は、図３の場合に、リアルタイム送受信を行なった後で、間引かれた２、４、６…のデータを継続して受信する場合を図示した模式図である。

この場合、４時間後に高品位のデータが全て揃うことになる。

図５は、図３および図４のような送受信において、高品位コンテンツを再生する手続きを示す模式図である。

図５で示したように、データが揃った時点で受信したストリームデータの順番を再構築し治せば、高品位のコンテンツを後から見ることが可能となる。

図４の中の上のストリームのうち、１、３、５、７、９、１１のデータが送信が始まって２時間の間で送受信可能なリアルタイム視聴可能なデータである。２時間後から高品位のコンテンツを構築するために欠けているデータの送受信が始まり、２、４、６、８、１０、１２のデータが送受信される。最終的にこれらの２、４、６、８、１０、１２のデータとリアルタイム送受信で受信済みの１、３、５、７、９、１１と交互に並べ変えて、高品位の１、２、３、…１２のストリームデータを構築することができる。

実際には、高品位のコンテンツ視聴は２時間後から可能になる。最初に１、３、５、７、９を送受信し、２時間後から、２、４、６、８、１０を送受信する。２、４、６、８、１０の送受信は全体で２時間で可能であり、転送開始２時間後から１を再生し始めると同時に２を転送し始め、２時間１０分後に１の再生が終り、その時２は半分転送済みで、それを再生し始め、２時間２０分後に２の転送と再生が終る。２時間２０分後からは３の再生を始めると同時に４の転送を始め、以下、同様にして、２０分おきに４、６、８、１０、１２の転送と再生が終るかたちで処理を行なえばよい。

（ａ）システム構成図
図６は、本発明を含むシステム構成図であり、ストリームデータ送信装置１００とストリームデータ受信装置２００と通信回線４００とで構成される。

ストリームデータ送信装置１００は、コンテンツの映像や音声をエンコードするエンコード処理部１１０、エンコードした結果を保存しておくハードディスクの様なデータ蓄積部１２０、エンコードしたデータのうち、リアルタイム視聴のためにリアルタイムで送出するデータを選び出すデータ選択処理部１３０、送信するデータを管理する送信データ管理部１４０、実際にデータを送信する通信処理部１５０を備える。

ストリームデータ受信装置２００は、送信されてくるデータを受信する通信処理部２１０、受信したデータを管理する受信データ管理部２２０、受信したデータを保存するデータ蓄積部２６０、リアルタイムに受信したデータをデコードするリアルタイム受信データデコード部２３０、リアルタイムに受信したデータと後から受信したデータを併せて高品位のコンテンツを構築する蓄積データ再構築処理部２４０、再構築して出来た高品位データをデコードする蓄積データデコード部２５０、並びに、リアルタイムに受信したデータをデコードした映像や音声、再構築した後の高品位のコンテンツをデコードした映像や音声を出力するブラウン管やスピーカの様なコンテンツ出力部２７０、受信側から送信側に対して、コンテンツデータの送信リクエストを行なうための送信データ要求処理部２８０、送信データ要求処理部２８０に対して具体的なパラメータの指定を入力するためのキーボードやマウス、タッチパネルなどの送信データ要求入力部２９０を備える。

以下、本発明の送受信システム、すなわち、ストリームデータ送信装置１００およびストリームデータ受信装置２００の動作について、場合を分けて、さらに詳しく説明する。

（ｂ）リアルタイムデータ転送と蓄積データの転送、並びにその再構築を行なう場合
図７は、本発明の送受信システムの動作の一例を説明するためのフローチャートである。

また、図８は、通信回線速度が高品質データを送受信するのに必要な帯域の１／２しかない回線である場合を説明するための模式図であり、図９は、通信回線速度が高品質データを送受信するのに必要な帯域の１／４しかない回線である場合を説明するための模式図である。

図７を参照して、送信装置１００では、送信側において送信リクエスト開始処理の場合には（Ｓ１０２）、まず送信リクエスト開始処理を行うとともに（Ｓ１０４）、一方で、送信リクエスト開始処理でない場合には（Ｓ１０２）、データが終了していないときは（Ｓ１０６）、映像や音声のコンテンツのデータをエンコード処理部１１０にてエンコードし（Ｓ１０８）、データ蓄積部１２０に蓄積すると同時に（Ｓ１１０）、データ選択処理部１３０にて、リアルタイムにデータ転送を行なうか否かを判定する（Ｓ１１２）。

この判定は、通信回線の伝送速度（帯域）と、リアルタイムに伝送するのに必要な速度との関係で決るデータの間引きの間隔に基いて行う。例えば、ＭＰＥＧにおいては、通信回線速度が高品質データを送受信するのに必要な帯域の１／２しかない回線である場合には、図８に記載している様にＩピクチャ、Ｐピクチャ、Ｂピクチャを用いた圧縮でＩピクチャを使用する頻度を全フレームの１／２にし、残りをＰピクチャとすればよい。また、通信回線の速度が必要となる帯域の１／４である場合には、Ｉピクチャを使用するのは図９のように、Ｉ１、Ｉ５、Ｉ９と全体の１／４とし、残りはＰピクチャのみ、あるいは、ＰピクチャとＢピクチャとすれば良い。

判定結果は、先に記したストリームデータに順番に付けたシーケンス識別番号５０１をインデックスとし、送信済みか否かのテーブルとして、送信データ管理部１４０に記録してある情報に基づいて行なう。また、同時にリアルタイム転送を行なうデータである場合には、データを通信処理部１５０に転送して、通信回線４００を介してデータ転送し（Ｓ１１４）、送信データ管理部１４０に送信記録をつける（Ｓ１１６）、処理はステップＳ１０６に復帰する。

リアルタイム転送が終了した後（Ｓ１０６）、送信データ管理部１４０に記録されているリアルタイム転送が行なわれていないデータを識別番号の小さい順に見つけ出し（Ｓ１２０）、データ蓄積部１２０から該当データを取り出して、データ終了まで、送信データ管理部１４０にて転送を行なう（Ｓ１２２）。

一方、リアルタイム送信しない場合は（Ｓ１１２）、送信データ管理部に未送信記録をつける（Ｓ１１８）。

なお、ストリームデータに順番に付けるシーケンス識別番号５０１、並びに再生する時に時間調整のために使用するデータ再生時間タグはエンコードを行なって作成したデータをデータ蓄積部１２０に保存する時にデータに添付することで行なうことができる。

図１０は、受信装置２００側の処理を説明するためのフローチャートである。

受信装置２００では、受信側送信リクエスト開始処理を行ったのち（Ｓ２０２）、リアルタイムデータが終了していない場合は（Ｓ２０４）、送信装置１００から転送されるデータを通信処理部２１０で受信して、これをデータ蓄積部２６０に蓄積すると同時に（２０６）、リアルタイム受信データデコード部２３０によって、受信したデータのデコードを行ない（Ｓ２０８）、リアルタイム視聴を可能なデータに加工して、コンテンツ出力部２７０に出力する（Ｓ２１０）。受信装置２００では、これらのリアルタイム視聴が終了した後も（Ｓ２０４）、送信システムから継続して送信される高品位のコンテンツの受信を行ない、データ蓄積部２６０にデータを蓄積する（Ｓ２１２）。全てのデータの受信が終った時点で（Ｓ２１４）、記録した全てのデータをシーケンス識別番号５０１順に並び変えて高品位のデータを作り変える（Ｓ２１６）という処理をデータが終了するまで行う（Ｓ２１８）。

なお、受信側から送信側に対してはコンテンツデータの送受信のためのパラメータ指定を行なう必要があるため、送信データ要求リクエストを出す必要がある。パラメータとしてはコンテンツの番組や種類、通信回線の伝送速度、データを開始する位置、２倍、３倍といった再生速度、順方向、逆方向といった再生の方向等がある。

図１１は、このようなパラメータ指定を行うネゴシエーションを含む通信シーケンスを示す図であり、図１２は、この場合の受信側の処理を示すフローチャートであり、図１３は、送信側の処理を示すフローチャートである。

図１１、図１２および図１３を参照して、まず、受信側でタイトル名の入力が行われ（Ｓ３０２）、さらに回線速度、配信開始位置、倍速指定値、再生方向等のパラメータの入力が行われると（Ｓ３０４）、送信開始リクエストが送信側に向けて送信される（Ｓ３０６）。

送信側で送信リクエスト開始リクエストの応答を返信すると（Ｓ４０２）、送信側は受信待ちとなる（Ｓ４０４）。

受信側では、送信リクエスト開始リクエストの応答を受け取ると（Ｓ３０８）、タイトル名のリクエストを送信側に送る（Ｓ３１０）。

続いて、送信側では、タイトル名リクエストを受け取ると（Ｓ４０６）、タイトル名リクエストの応答を送信し（Ｓ４０８）、受信待ち状態となる（Ｓ４１０）。

受信側では、タイトル名リクエストの応答を受信して、タイトル名リクエストの受理を確認すると（Ｓ３１２）、続いて、パラメータ指定リクエストを送信する（Ｓ３１４）。

送信側では、パラメータ指定リクエストを受け取ると（Ｓ４１２）、パラメータ指定リクエストの応答を送信して、パラメータの取り込み処理が行われ（Ｓ４１４）、引き続きストリームの送信が行われる（Ｓ４１６）。

受信側では、パラメータ指定リクエストの応答を受信して、パラメータ指定リクエストが受信されたことを確認した後（Ｓ３１６）、ストリーム受信処理を開始する（Ｓ３１８）。

なお、ストリームデータの受信処理の終了時には、受信側から最終データ受信のアクノーリッジ（ＡＣＫ）信号が送信され、送信側からデータ終了通知がされると、受信側からデータ終了通知に対するＡＣＫ信号が送信されて、セッションが終了する。

（ｃ）（ｂ）において、送信側で予めエンコードデータを作成する場合
上述した（ｂ）の場合では、リアルタイムにエンコードを行なう場合について記載しているが、予めエンコード処理部１１０にてコンテンツデータを全てエンコードしてデータ蓄積部１２０のデータを保存した後で、データ選択処理部１３０、送信データ管理部１４０、通信処理部１５０の処理を繰り返して同様のことを行なうこともできる。

図１４は、送信側で予めエンコードデータを作成する場合のフローチャートである。

図１４を参照して、送信装置１００では、ストリーム送信処理が開始されると、データが終了していないときは（Ｓ５０２）、映像や音声のコンテンツのデータをエンコード処理部１１０にてエンコードし（Ｓ５０４）、データ蓄積部１２０に蓄積し（Ｓ５０６）、処理をステップＳ５０２に復帰させ、蓄積済みのデータが送信するべきデータの終了となるまで、Ｓ５０２〜Ｓ５０６の処理を繰り返す。

次に、送信済みのデータが終了まで達しているか否かを判定し（Ｓ５０８）、データ選択処理部１３０にて、リアルタイムにデータ転送を行なうか否かを判定する（Ｓ５２０）。

判定結果は、先に記したストリームデータに順番に付けたシーケンス識別番号５０１をインデックスとし、送信済みか否かのテーブルとして、送信データ管理部１４０に記録してある情報に基づいて行なう。また、リアルタイム転送を行なうデータである場合には、データを通信処理部１５０に転送して、通信回線４００を介してデータ転送し（Ｓ５２２）、送信データ管理部１４０に送信記録をつける（Ｓ５２４）、処理はステップＳ５２０に復帰する。

リアルタイム転送が終了した後（Ｓ５０８）、送信データ管理部１４０に記録されているリアルタイム転送が行なわれていないデータを識別番号の小さい順に見つけ出し（Ｓ５１０）、データ蓄積部１２０から該当データを取り出して、データ終了まで、送信データ管理部１４０にて転送を行なう（Ｓ５１２）。

一方、リアルタイム送信しない場合は（Ｓ５２０）、送信データ管理部に未送信記録をつける（Ｓ５２６）。

送信側で予めエンコードデータを作成している場合には、任意の位置からリアルタイム視聴が可能になる。また、受信のための他のパラメータの変更も可能になる。

図１５は、このようにして、途中からパラメータを変更する場合の送受信パケットシーケンスを示す図である。

たとえば、データ開始位置の変更を可能とするために、受信側はコンテンツデータのデータ再生時間タグ５０２を指定して、送信側に再生開始時間の要求を送る。このようにすることで、ストリーム受信の途中からパラメータの変更が可能になる。

この処理は、送信データ要求入力部２９０と送信データ要求処理部２８０で行なう。送信側は、時間指定のリクエストが受信側から送られた場合、送信データ管理部１４０の中にある個々のデータのデータ再生時間タグを検索し該当するデータが含まれている位置を検出し、それ以降はこの位置から以降のデータを送信する。

次にデータ選択処理部１３０で具体的な高品位のコンテンツデータを間引いてデータ伝送帯域の狭い通信路のためのリアルタイムデータを選択する具体的な方法について記載する。

（ｄ）高品位コンテンツデータからリアルタイムのストリームデータを作成する場合
現在、ビデオＣＤや、ＤＶＤ等で広く使用されているＭＰＥＧ１やＭＰＥＧ２を用いたコーデックを例として実施の形態を記載する。

これらのコーデックでは、動画を圧縮するために、元データをＩピクチャ、Ｐピクチャ、Ｂピクチャと呼ばれるピクチャに分割する。Ｉピクチャは動画を構成する複数のフレームの一定期間毎のフレームをそのまま圧縮したものであり、このＩピクチャのみを連続再生した場合でも動画としては完結した映像となるために独立して試聴する事が可能である。例えば毎秒３０枚のフレームのうちの１／３の１０枚をＩピクチャとして使用してそれらを１秒間で再生した場合、飛び飛びの映像を見ることになる。実際に試聴した場合にはどの程度データを間引くかにより、動画の動きが多少ぎこちなく、角々と動く映像である様に感じる場合がある。

図１６は、４フレーム毎にIピクチャを送受信する場合を示す図である。

ここで矩形の中の数値は前述のストリームデータの順番に対応して付けたシーケンス識別番号５０１である。また、小数点数字はコンテンツがスタートしてから、そのデータが再生されるべき経過時間を表したデータ再生時間タグ５０２である。これらの数値は個々のストリームデータの属性としてそれぞれのデータに付加されている。

これらのＩピクチャに対して、動画は多くの場合に連続して変化するため、あるフレームとその後のフレームとの間には映像データとしては共通部分が多く、この性質を利用してあるフレームの後のフレームの予想を行ない、その差分のデータを用いて動画の圧縮率を上げることが可能となる。

このように過去のＩピクチャを元にして後続するフレームの予想を行ない、その差分のみを符号化したものがＰピクチャである。更に未来のＩピクチャや前述のようにして作成したＰピクチャもこの予想を行なうためのデータとして使用したものがＢピクチャである。

図１７は、これらＩピクチャ５１０、Ｐピクチャ５２０、Ｂピクチャ５３０の関係を記載した図である。図ではＩピクチャは１番目のデータＩ１と１０番目と３０番目のデータＩ１０、Ｉ３０であり、ＰピクチャはＰ４、Ｐ７、ＢピクチャはＢ２、Ｂ３、Ｂ５、Ｂ６、Ｂ８、Ｂ９、Ｂ１１である。

高品位コンテンツデータからリアルタイムの視聴のためにデータを間引いたデータを作る方法として、このＩピクチャのみをリアルタイム転送で送信し、リアルタイム再生が終了した時点から、それぞれのＩピクチャに対応した、ＰピクチャとＢピクチャを送信する方法が考えられる。受信側では、リアルタイム視聴時に蓄積した I ピクチャと高品位データの一部として送信されるＰピクチャとＢピクチャとをそれぞれデータに付加されたデータのシーケンス識別番号順に並び直した高品位データを再構築していくことが可能となる。この処理を図示したのが前述の図５である。

この場合、Ｉピクチャは飛び飛びのフレームであるため、再生する場合には、個々のＩピクチャの表示時間を長くする必要がある。先に記した１秒辺り３０枚のフレームを再生する場合、３０枚全てのフレームを使用して再生する場合には、１枚辺りの表示時間は約０．０３秒となるが、この３０枚うちの１／３の１０枚のみ用いてリアルタイムで転送する場合には受信側では個々のフレームの表示を３倍の０．０９秒だけ表示する必要がある。この表示時間の調節のためには、元データのフレーム間の時間間隔である元データフレーム間時間間隔５０３とデータ再生時間タグ５０２を使用する。

すなわち、図１６において、最初のＩピクチャＩ１のデータ再生時間タグは０であり、次のＩピクチャＩ４のデータ再生時間タグは０．０９であるため、Ｉ１は０〜０．０９秒の間表示を続ける。同様にしてＩ４ピクチャの表示は０．０９〜０．１８秒の間表示する。

図１８は、以上のような図１６の処理シーケンスを示すフローチャートである。

まず、ｔ１：Ｉピクチャｎの再生時間タグを取得する（Ｓ６０２）。次に、ｔ２：Ｉピクチャｎ＋１の再生時間タグを取得する（Ｓ６０４）。時間差Δｔ＝ｔ２−ｔ１を演算し（ステップＳ６０６）、時間Δｔだけフレームｎを出力する（Ｓ６０８）。

なお、以上の記載は簡便のためにＩピクチャだけをリアルタイム送受信時に使用する例を記載しているが、Ｉピクチャだけでなく、ＰピクチャやＢピクチャの一部を使用してリアルタイム送受信を行なうことも可能である。

（ｅ）早送りや巻き戻しの時の転送データも蓄積データの一部として利用して高品位データの全体のデータ転送量を増やす事なく実現する場合
上記（ｃ）の場合で記載している様に予め送信側で元データがエンコードされている場合には、任意の場所からの順方向の早送りや逆方向の早送りが可能となる。

データの早送り自体はリアルタイム送信の方法と同様にＩフレームのみを送受信することで可能である。

図１９は、順方向の早送りを説明するための模式図である。

順方向の早送りの場合には、Ｉピクチャを時間軸の順番で送受信してそれぞれのフレームの表示時間を短くすることで実現できる。１秒辺り３０枚の元データである場合には、このうちの１０枚を送受信し、それそれを０．０３秒間の表示時間とすれば３倍の早送りを行なうことになる。１５枚を送受信し、それそれを０．０３秒間の表示時間にすれば２倍の倍速再生を行なうことになる。

図２０は、逆方向の早送りを説明するための模式図である。

逆方向の早送りの場合には、Ｉピクチャの送受信の順番を逆にすれば可能になる。

すなわち、Ｉ１、Ｉ２、Ｉ３、Ｉ４、Ｉ５、Ｉ６、Ｉ７、Ｉ８、Ｉ９、Ｉ１０と時間軸に応じた元データがある場合に、Ｉ１０、Ｉ９、Ｉ８、・・・と送信して受信側では受信した順番で表示を行なえば逆再生ができる。この時に、１／３のデータを送受信してそのまま再生すれば３倍の逆早送りを行なうことになる。例えば、Ｉ１０、Ｉ７、Ｉ４、Ｉ１と送信してそれぞれを０．３秒間の表示を行なうことにすれば３倍の逆早送りができる。

早送りや逆早送りの開始位置は、上記（ｃ）の場合で記載しているように任意の位置からの普通再生を行なう場合と同様に、送信側から送信データ要求を行なうことで可能である。２倍、３倍といった速度指定や、早送りか逆早送りであるかという選択も送信データ要求処理部２８０を介して送信側にリクエストを行なうことで可能である。

標準的なリアルタイム送受信や蓄積送受信を行なっている最中にこうした送受信モードの切替を行なうパケットレベルでのシーケンスは、図１５に記載したものを用いればよい。データｎを受信した後、データｎのＡＣＫ信号を返す代わりに、受信側から送受信リクエスト開始リクエストを送信側に返してやる。

こうして早送りや逆早送りで送受信したデータも高品位データ全体のデータの一部として利用するには、早送りや逆早送りで送受信するデータについても、送信データ管理部１４０と受信データ管理部２２０に送受信したデータのシーケンス識別番号を記録し、送信側でリアルタイム送受信が終って、高品位のデータを送信する場合にすでに早送りや逆早送りで送受信が終っているデータを送信しない様にすることで可能になる。受信側では早送りしない場合には送られてこなかったデータが既に早送り再生時に送られて来ているだけであり、データの再構築時にシーケンス識別番号５０１通りにデータを並べ変える処理は早送りしない場合と同じである。

（ｆ）データ送受信の速度計測を行う方法
上記（ａ）の場合で説明した部分では、受信側から送信側に対してコンテンツ送受信のためのパラメータを指定する例を記載していた。

この場合にはユーザが通信回線速度を送信データ要求入力部２９０で入力して指定していたが、通信回線の伝送速度については自動的に計測することも可能である。

そのためには、送信側が通信回線速度計測処理部１６０を用いて送信側から受信側に対して通信回線速度計測リクエストを送信する。受信側ではこのリクエストを受信した場合には通信回線速度計測処理部３００を用いて通信回線の速度を計測する。

たとえば、図２１は、ｆｔｐプロトコルのようなファイル転送プロトコルを用いて送信側から大きなファイルをダウンロードしてファイルのサイズとファイルの送信に要した時間から通信回線速度を計算する処理を示す図である。ファイル転送を用いた速度計測は、コンテンツ送受信の直前に行い、コンテンツ送受信時の初期パラメータ設定に利用することができる。

ＵＤＰのようなＡＣＫ信号を返さないデータ送受信においては、単位時間ごとに受信側でデータ受信量を計測し続けることでデータ送受信の速度を計算し、監視することができる。

データ送受信の速度を自動計測し、監視する方法は、後に記載している（ｇ）の場合の通信回線の帯域変化への対応に利用することができる。

（ｇ）急な帯域の変化に対応してリアルタイムストリームのデータ量を変化させる場合
図１１等で記載しているように、パケットの送受信のシーケンスでは、送信側が送信したデータを受信側が受信したことを送信側に知らせるために、個々のデータについてＡＣＫ信号を返している。このＡＣＫ信号が返ってきたことによって送信側は次のデータを送ることができる。もしこのＡＣＫ信号が返ってこない場合、何らかの理由でデータが送受信できなかったことを意味する。一般にＴＣＰ／ＩＰを用いた通信ではＡＣＫ信号が返ってこない場合には再送処理が自動的に行われる。

それでもＡＣＫ信号が返ってこない場合には、（ｆ）で記載したデータ送受信の速度計測を行って通信回線の速度を計測しなおすことができる。例えば、同じ通信回線を用いて本方式による様な別のリアルタイム視聴を始めた様な場合、先にリアルタイム送受信を行なっていて試聴していた時に使用できていた帯域が約１／２に落ちてしまうことになる。

このような場合にはリアルタイムでのデータ送受信データ量を変えることによって対応を行なうことが可能である。すなわち、図８で表されるリアルタイムデータ作成処理から図９で表されるリアルタイムデータ作成方法に切替えることで、１／２の速度になった場合にも本方式によるリアルタイム送受信と後からの蓄積データのためのデータ送受信が可能となる。

映像などのストリームデータの送受信を行なう場合、ＵＤＰを用いる場合が多いが、その場合は上記のようなＡＣＫ信号を利用する方法を用いることができない。そのような場合は、（ｆ）でも述べたように受信側で単位時間ごとのデータ受信量を計測し、それに基づいて算出されたデータ送受信速度を送信側に知らせることで、送信側は受け取ったデータ送受信速度に基づいて送信するデータの間引き間隔を動的に調整することが可能になる。

以上、実施の形態としてはＭＰＥＧに基づく記載を行なってきたが、本方式によるデータの送受信はＭＰＥＧに限定されることなく使用することが可能である。たとえば、非圧縮な映像データやモーションＪＰＥＧ（motion-JPEG）のような時系列な画像データで構成されるような映像などでも、リアルタイム時にはデータを後で再構成可能なようにしてフレーム単位でデータを間引いて送受信し、リアルタイム視聴時に送受信しなかったデータはリアルタイム視聴後に引き続いて送受信して受信側で完全なデータとして再構成して蓄積することができる。本発明におけるストリームデータを後で再構成可能なように間引いて送受信する方法自体は特定の方法に限定されるものではないのである。

また、以上の説明では個々のデータの中は映像データだけでなく、音声データも一緒に含まれるという事で記載しているが、音声データは映像データに比べてデータ量が極めて少なくて済む。例えばＭＰＥＧ２の場合であれば映像データは数Ｍｂｐｓの帯域を要するが、音声データの場合には数１０Ｋｂｐｓで済む。従って、音声データについては映像データのように間引いて送受信することなく、全てのデータを送受信しても全体としての帯域に対しての影響は非常に少ない。

図２２は、音声データについては映像データのように間引いて送受信しない場合にリアルタイムで送受信されるデータについて摸式的に示した図である。

ここでは細い縦長の矩形を音声データ５０４として表している。この場合には送受信で送信、受信のデータを管理する処理で映像と音声については別々の管理が必要となる。具体的にはデータ選択処理部１３０では映像と音声を別データパケットとして扱い、送信データ管理部１４０ではそれぞれを別々に送信済みであるかを管理し、受信側でも受信データ管理部２２０でそれぞれを別々に管理する必要がある。

以上に述べてきた機能を処理プログラムとしてそれらの少なくとも一つをコンピュータに読取可能な記憶媒体に記録し、ソフトウェアとして実現することも可能である。

この場合、図６に示したストリームデータ送信装置１００またはストリームデータ受信装置２００は、それぞれ、媒体からこのプログラムを読み取るためのドライブ装置をさらに備える。

たとえば、ストリームデータ送信装置１００では、エンコード処理部１１０、データ選択処理部１３０、送信データ管理部１４０、通信処理部１５０、通信回線速度計測処理部１６０の行う処理をＣＰＵ（図示せず）上で動作するプログラムにより実現できる。

また、ストリームデータ受信装置２００でも、通信処理部２１０、受信データ管理部２２０、リアルタイム受信データでコード部２３０、蓄積データ再構築処理部２４０、蓄積データでコード部２５０、送信データ要求処理部２８０、通信回線速度計測処理部３００の行う処理をＣＰＵ（図示せず）上で動作するプログラムにより実現できる。

したがって、この場合は、ストリームデータ送信装置１００またはストリームデータ受信装置２００は、通信機能を有する汎用のコンピュータにおいて、上記プログラムをインストールすることによっても実現できる。

以上のように使用する通信回線の伝送速度が高品位のコンテンツの送受信に不十分な帯域しかないためにリアルタイムに高品位な品質で試聴できない場合でも高品位ではないがリアルタイムの視聴を可能にしつつ、リアルタイムで送受信するデータが最終的な高品位のコンテンツデータの一部を成し、後から同じコンテンツを高品位に視聴することを可能にするが、全体として送受信されるデータサイズは高品位のデータサイズと等しく、通信回線の帯域をより有効に活用できる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

通信回線の伝送速度が十分確保されている場合の送受信を示す摸式図である。 通信回線の伝送帯域が半分しか確保できない通信回線を使用して受信する場合を説明するための模式図である。 図２の通信回線を用いて、リアルタイムにコンテンツを視聴する場合を説明するための模式図である。 図３の場合に、リアルタイム送受信を行なった後で、間引かれた２、４、６…のデータを継続して受信する場合を図示した模式図である。 図３および図４のような送受信において、高品位コンテンツを再生する手続きを示す模式図である。 本発明を含むシステム構成図である。 本発明の送受信システムの動作の一例を説明するためのフローチャートである。 通信回線速度が高品質データを送受信するのに必要な帯域の１／２しかない回線である場合を説明するための模式図である。 通信回線速度が高品質データを送受信するのに必要な帯域の１／４しかない回線である場合を説明するための模式図である。 受信装置２００側の処理を説明するためのフローチャートである。 パラメータ指定を行うネゴシエーションを含む通信シーケンスを示す図である。 受信側の処理を示すフローチャートである。 送信側の処理を示すフローチャートである。 送信側で予めエンコードデータを作成する場合のフローチャートである。 途中からパラメータを変更する場合の送受信パケットシーケンスを示す図である。 ４フレーム毎にIピクチャを送受信する場合を示す図である。 Ｉピクチャ５１０、Ｐピクチャ５２０、Ｂピクチャ５３０の関係を記載した図である。 図１６の処理シーケンスを示すフローチャートである。 順方向の早送りを説明するための模式図である。 逆方向の早送りを説明するための模式図である。 ファイル転送プロトコルを用いて送信側から大きなファイルをダウンロードしてファイルのサイズとファイルの送信に要した時間から通信回線速度を計算する処理を示す図である。 音声データについては映像データのように間引いて送受信しない場合にリアルタイムで送受信されるデータについて摸式的に示した図である。

符号の説明

１００ 送信装置、１１０ エンコード処理部、１２０ データ蓄積部、１３０ データ選択処理部、１４０ 送信データ管理部、１５０ 通信処理部、１６０ 通信回線速度計測処理部、２００ 受信装置、２１０ 通信処理部、２２０ 受信データ管理部、２３０ リアルタイム受信データデコード部、２４０ 蓄積データ再構築処理部、２５０ 蓄積データデコード部、２６０ データ蓄積部、２７０ コンテンツ出力部、２８０ 送信データ要求処理部、２９０ 送信データ要求入力部、３００ 通信回線速度計測処理部、４００ 通信回線、５０１ シーケンス識別番号、５０２ データ再生時間タグ、５０３ 元データフレーム間時間間隔、５０４ 音声データ、５１０ Ｉピクチャ、５２０ Ｐピクチャ、５３０ Ｂピクチャ。

Claims (7)

1. あらかじめエンコードされたストリームデータを格納しておくデータ蓄積手段と、
   前記ストリームデータを受信する受信装置からの、倍速指定値および再生方向の少なくともいずれかを含む視聴要求に応じて、前記ストリームデータを指定した間隔で間引いて選択するデータ選択処理手段と、
   送信するストリームデータを前記データ選択処理手段により選択された選択データと選択されなかった非選択データとに分けて管理する送信データ管理手段と、
   前記視聴要求に対して、前記送信データ管理手段で管理される前記選択データを、前記倍速指定値および前記再生方向の少なくともいずれかに応じて再生されるべき経過時間を表したデータ再生時間タグと前記ストリームデータにおける順番を表すシーケンス識別番号とを付して、リアルタイム送信する第１送信手段と、
   前記視聴要求に対する前記選択データのリアルタイム送信が終了した後に、前記送信データ管理手段で管理される前記非選択データを、前記シーケンス識別番号を付して前記受信装置に対して送信する第２送信手段とを備え、
   前記第２送信手段は、前記受信装置に対して、前記受信装置からの新たな視聴要求を受け付けることなく前記非選択データを送信し、
   前記選択データは、前記受信装置において前記データ蓄積手段が保持するストリームデータを順方向に早送り再生をするためのデータ、または当該受信装置において当該ストリームデータを前記順方向とは逆の方向に早送り再生をするためのデータである、ストリームデータ送信装置。
2. 前記データ選択処理手段においてデータを間引くための間隔は、通信回線の通信速度とデータをリアルタイムに伝送するのに必要な速度との関係に基づいて決定される、請求項１に記載のストリームデータ送信装置。
3. 通信中における通信路の通信性能の変化に対応して、前記ストリームデータの間引きの条件を変化させる、請求項１または２に記載のストリームデータ送信装置。
4. 請求項１〜３のいずれか１項に記載しているストリームデータ送信装置から、前記選択データと前記非選択データとを受信する受信手段と、
   前記受信した選択データと非選択データとから前記ストリームデータを再構築する再構築処理手段とを備える、受信装置。
5. 前記受信手段は、
   前記ストリームデータ送信装置に対する、前記視聴要求を示した要求信号の送信に基づき、前記選択データを受信し、
   前記ストリームデータ送信装置に対して、前記新たな視聴要求を示した要求信号を送信することなく、前記非選択データを受信する、請求項４に記載の受信装置。
6. 請求項１〜３のいずれか１項に記載しているストリームデータ送信装置の処理をコンピュータに実行させるための処理プログラムを記録した記録媒体。
7. ストリームデータを送信する送信装置と、前記ストリームデータを受信する受信装置とを備えたシステムであって、
   前記送信装置は、
   あらかじめエンコードされたストリームデータを格納しておくデータ蓄積手段と、
   前記ストリームデータを受信する受信装置からの、倍速指定値および再生方向の少なくともいずれかを含む視聴要求に応じて、前記ストリームデータを指定した間隔で間引いて選択するデータ選択処理手段と、
   送信するストリームデータを前記データ選択処理手段により選択された選択データと選択されなかった非選択データとに分けて管理する送信データ管理手段と、
   前記視聴要求に対して、前記送信データ管理手段で管理される前記選択データを、前記倍速指定値および前記再生方向の少なくともいずれかに応じて再生されるべき経過時間を表したデータ再生時間タグと前記ストリームデータにおける順番を表すシーケンス識別番号とを付して、リアルタイム送信する第１送信手段と、
   前記視聴要求に対する前記選択データのリアルタイム送信が終了した後に、前記送信データ管理手段で管理される前記非選択データを、前記シーケンス識別番号を付して前記受信装置に対して送信する第２送信手段とを備え、
   前記第２送信手段は、前記受信装置に対して、前記受信装置からの新たな視聴要求を受け付けることなく前記非選択データを送信し、
   前記選択データは、前記受信装置において前記データ蓄積手段が保持するストリームデータを順方向に早送り再生をするためのデータ、または当該受信装置において当該ストリームデータを前記順方向とは逆の方向に早送り再生をするためのデータであり、
   前記受信装置は、
   前記送信装置から、前記選択データと前記非選択データとを受信する受信手段と、
   前記受信した選択データと非選択データとから前記ストリームデータを再構築する再構築処理手段とを備えることを特徴とする、システム。

Images