JP5322518B2

JP5322518B2 - 通信方法

Info

Publication number: JP5322518B2
Application number: JP2008178451A
Authority: JP
Inventors: 肇大嶋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-07-08
Filing date: 2008-07-08
Publication date: 2013-10-23
Anticipated expiration: 2028-07-08
Also published as: JP2010021663A; US20100011402A1; US8434119B2

Description

本発明は、通信方法に関し、伝送路を介して映像をリアルタイムに配信する映像配信システムに用いて好適なものである。

近年、動画像データの符号化技術が進歩するとともに、ネットワークの大容量化、伝送技術が発達している。これにより、ＶＴＲやＤＶＤ等の記録媒体に物理的に蓄積された映像を視聴するという従来の視聴スタイルから、インターネット等のネットワークを介して視聴したい映像コンテンツを受信する「ビデオ・オン・デマンド」といった視聴スタイルに変化しつつある。

また、ネットワークを介した映像コンテンツの配信方法として、伝送路に応じた小サイズのパケットに分割して時系列順に送信するといった、ストリーミング型と呼ばれる方式（ストリーミング配信）がある。映像コンテンツをストリーミング配信することにより、記憶容量が少ない視聴端末でも映像コンテンツを保存するための容量を意識することなく映像をリアルタイムに鑑賞することができる。

このようなストリーミング配信は、ウェブ（Ｗｅｂ）カメラで撮影した映像をインターネットでリアルタイムにライブ配信するという利用形態が典型的である。しかし、これに限らず、コンテンツサーバに予め保存されている動画コンテンツをストリーミング視聴するという利用形態もある。

一般的には、ストリーミング配信をインターネット上で行うには、ＩＥＴＦ（Internet Engineering Task Force）により規定されているインターネット標準通信プロトコルのうち、ＲＴＳＰやＲＴＰが主に用いられる。ＲＴＳＰ（Real Time Streaming Protocol）は、再生セッション開始・コンテンツ情報取得・再生・停止といった再生制御に用いられ、ＲＦＣ２３２６で定められる。ＲＴＰ（A Transport Protocol for Real-Time Applications）は、映像データ配信の基本プロトコルであり、ＲＦＣ１８８９、ＲＦＣ３５５０で定められる。また、ＲＴＳＰやＲＴＰに加えて、映像データの伝送には符号化形式に準じた標準プロトコルが用いられる。例えば、ＭＰＥＧ−４Ｖｉｄｅｏの場合には、ＲＦＣ３０１６（RTP Payload Format for MPEG-4 Audio/Visual Streams）がＲＴＰと併用される。

ストリーミング配信方式で、映像コンテンツの早送り再生・巻き戻し再生を行う方法については、ＲＴＳＰ仕様中に記述されている。一例として、ＲＴＳＰ及びＲＴＰを用いて、ＭＰＥＧ−４Ｖｉｄｅｏ形式で符号化されている映像コンテンツを視聴中に早送り再生モードに切り替えて配信する場合の通信シーケンスを図１に示す。図１に示す配信サーバ（Ｓ）及びクライアント端末（視聴端末）（Ｃ）間の通信シーケンスは、通常再生の途中にクライアント端末にて早送り再生に係る操作が行われたときに開始される。

まず、クライアント端末は、再生セッションを開始するためのDESCRIBE（セッション開始）コマンドを配信サーバに送信する。DESCRIBEコマンドを受信した配信サーバは、該コマンドに対する応答をクライアント端末に返す。

次に、クライアント端末は、配信サーバにSETUP（配信設定）コマンドを発行して配信準備を行う。SETUPコマンドを受信した配信サーバは、映像データの送受信に必要な設定情報を応答として返す。

そして、クライアント端末は、映像コンテンツの再生を開始するためにPLAY（再生）コマンドを配信サーバに送信する。配信サーバは、PLAYコマンドを受信したら応答を返すとともに、映像データをＲＴＰで送信する。

ここまでが通常再生の流れであるが、次に、図１において後半に示される通常再生の途中に早送り再生（高速再生）を行う場合のシーケンスについて説明する。ここでは、６０秒の映像データの再生中に、１２秒目まで再生された時点で早送り再生に係る操作が行われたものとして説明する。また、早送り再生の速度は５倍であるものとする。

クライアント端末は、通常再生中に早送り再生に係る操作が行われ、早送り要求が発生した時点で、現在の通常再生モードでの配信を一時停止するためにPAUSE（一時停止）コマンドを配信サーバに送信する。配信サーバは、クライアント端末からPAUSEコマンドを受信すると、そのクライアント端末との接続を維持したまま、映像データの配信を停止する。

その後、クライアント端末は、早送り再生を行うために再度PLAYコマンドを配信サーバに送信する。ただし、このPLAYコマンドは最初のPLAYコマンドとは異なり、１２秒目の映像から５倍の再生速度で再生を要求している。

具体的には、図１において、１０１で示されるRangeフィールドは再生する範囲を示しており、“Range: npt=12.000000-60.000000”で示される部分が１２秒目からの（１２秒目から６０秒目までの）再生要求を表している。また、１０２で示されるScaleフィールドは再生速度を示しており、“Scale: 5”で示される部分が再生速度を５倍にすることを表している。

なお、Scaleフィールドの値に負の値を指定することで巻き戻し再生を要求することも可能である。また、ＲＴＳＰ仕様では、Scaleフィールドと同様の意味を持つSpeedフィールドも定義されており、Scaleフィールドの代わりに用いられることもある。

このように２回目のPLAYコマンド（早送り再生を行うためのPLAYコマンド）では、Rangeフィールドによって、早送り再生開始時刻からコンテンツの最後を示す終了時刻までが指定されている。このPLAYコマンドを受信した配信サーバは、指定された１２秒目の時点から５倍速で映像データを配信するようになっている。

しかしながら、上述したシーケンスには次のような問題点がある。
Scale（又はSpeed）フィールドで指定された再生速度が通常よりも高速で、送信される映像データの量がクライアント端末の処理能力を超える場合には、クライアント端末にて映像データを処理しきれずに再生動作に異常をきたす可能性がある。

また、送信される映像データ量が配信サーバとクライアント端末間のネットワークの帯域幅を超過するような場合には、映像データの伝送中に輻輳やパケットロス等のネットワーク障害を招くことが考えられる。その結果、クライアント端末での再生動作に異常をきたす可能性があるばかりか、そのネットワークに属する他のノードのパケット送受信処理も正常に行えなくなってしまうおそれがある。

例えば、高速再生時の再生速度をｎ（ｎ＝１の場合が通常速度の再生）とすると、高速再生時のビットレートは通常速度での再生時のビットレートのｎ倍となる。通常速度での再生時のビットレートをＢとし、ネットワークの伝送可能な最大ビットレートをＸとすると、Ｘ＜（Ｂ×ｎ）となる場合に上述のようなネットワーク障害が発生し得る。

また、ＭＰＥＧ形式などのように画面間予測符号化（フレーム間予測符号化）された映像データを含む場合、Rangeフィールドで指定された再生開始時刻の映像は、必ずしもその時刻の映像データのみで正常に復号・再生できるとは限らない。指定された時刻の映像データが画面間予測符号化ピクチャ（いわゆるＰピクチャ、Ｂピクチャ）である場合には、その時刻の映像を正しくデコードして再生するためには該当ピクチャの参照ピクチャのデータもデコード時に必要になる。よって、画面間予測符号化された映像データを含む場合には、指定された時刻の映像データを単純に送信するだけではクライアント端末で復号した結果が保証されず、異常な再生動作になる可能性がある。

従来のストリーミング型の映像配信システムにおいて、ピクチャのデータは、早送り再生・巻き戻し再生を行う際にも通常のシーケンスで送信されるため、受信側であるクライアント端末で特殊な再生処理を行わなければならなかった。特に、巻き戻し再生を行うには、ＭＰＥＧにおけるＧＯＰ（Group Of Picture）全体のデータを取得・デコードしておき、取得したピクチャ及びデコード後の表示画像を逆順で再生するために記憶しておく必要があり、コストの高いものであった。

従来、特殊再生処理を実現する技術としては、ストリーミングメディアコンテンツのクライアント端末側でのキャッシングの技術があった（例えば、特許文献１参照。）。特許文献１に記載のキャッシングの技術は、クライアント端末でストリーミングメディアをキャッシュする。これにより、各種のシャトルコントロールオプション（例えば、一時停止、停止、早送り、シーク、巻き戻しなど）が選択された際でも、コンテンツのストリーミングを継続することを可能にするものであった。

特開２００４−５４９３０号公報

しかしながら、前記特許文献１に記載のような従来の技術では、クライアント端末にストリーミング配信されたコンテンツデータを記憶するために、十分な容量の一時記憶が必要となる。したがって、上述したキャッシングの技術は、パーソナル・コンピュータなどの大容量の記憶装置を備えたクライアント端末では有効である。一方、携帯端末など大容量の記憶装置を備えることが物理的及び費用的に困難なクライアント端末の場合には、上述したキャッシングの技術は現実的ではなく、その技術で特殊再生を実現しようとするとクライアント端末のコストが増大するという問題があった。

また、上述した従来のキャッシングの技術では、クライアント端末側にキャッシュされた配信済みの映像データを用いて特殊再生を行うため、巻き戻し再生の場合には適用可能であるが、順方向の高速再生の場合にはまったく適用できない。したがって、上述した従来のキャッシングの技術を適用して順方向の高速再生を行う場合には、ネットワークのトラフィック増大による伝送障害やクライアント端末の負荷増大による再生異常といった不具合を改善することはできない。

本発明は、コストを増大させることなく許容される負荷に応じて、早送り再生及び巻き戻し再生を含む特殊再生を行えるようにすることを目的とする。

本発明に係る通信方法は、伝送路を介して送信装置からストリーミング送信される映像データを受信する受信装置の通信方法であって、受信手段が、前記映像データを受信する受信工程と、記憶手段が、受信した映像データを記憶する記憶工程と、監視手段が、前記記憶手段に記憶されている現在の映像データの量を監視する監視工程と、前記記憶手段に記憶されている現在の映像データの量が前記記憶手段に記憶できる映像データの上限量を超えた場合に、画面内符号化された映像データの要求と前記映像データの再生速度とを含む再生制御要求を、送信手段が前記送信装置に送信する送信工程と、再生手段が、前記受信手段が受信した映像データに対応するフレームを再生する再生工程とを有し、前記再生制御要求に前記画面内符号化された映像データの要求が含まれ、かつ、前記再生速度に応じたフレーム間隔よりも、前記送信装置に保持され画面内符号化された第１のフレームから前記第１のフレームの次に画面内符号化された第２のフレームまでのフレーム間隔が長い場合に、前記受信工程において、前記第１のフレームから前記再生速度に応じたフレーム間隔だけ再生順序が後であり前記第２のフレームよりも前である第３のフレームにかえて前記第２のフレームを前記受信手段が受信するか、または、前記第３のフレームを画面内符号化した第４のフレームを前記第３のフレームにかえて前記受信手段が受信するかを、前記送信装置に接続された受信装置の数に応じて切り替えて前記映像データを受信し、前記再生工程において、前記受信工程において前記第２のフレームを受信した場合には前記第１のフレームを再生した後、前記第１のフレームから前記再生速度に応じたフレーム間隔だけ再生順序が後の前記第３のフレームにかえて前記第２のフレームを前記再生手段が再生し、前記受信工程において前記第４のフレームを受信した場合には前記第３のフレームにかえて前記第４のフレームを前記再生手段が再生することを特徴とする。

本発明によれば、映像データを受信する装置に大容量の記憶装置を備えずに、かつ低負荷で早送り再生や巻き戻し再生を行うことができ、コストを増大させることなく許容される負荷に応じた、早送り再生及び巻き戻し再生を含む特殊再生を行うことができる。

以下、本発明の実施形態を図面に基づいて説明する。

まず、後述する本発明の各実施形態に係る通信システムの構成について説明する。
図２は、本発明の実施形態に係る通信システム（映像配信システム）の構成例を示すブロック図である。本実施形態における通信システムは、ストリーミング型の映像配信システムであり、送信装置（映像コンテンツの配信サーバ）３０としてのサーバ装置と、受信装置（映像コンテンツのクライアント端末（視聴端末））１０としてのクライアント装置とを有する。送信装置３０としてのサーバ装置と受信装置１０としてのクライアント装置とは、伝送路であるインターネット等のネットワークを介して通信可能となっており、送信装置３０から受信装置１０へ映像データがストリーミング送信される。例えば、サーバ装置やクライアント装置は、それぞれ単一のコンピュータ装置で実現してもよい。また、例えば、互いに通信可能なようにＬＡＮ（Local Area Network）やＵＳＢ（Universal Serial Bus）などで接続された複数のコンピュータ装置に各機能を分散し実現するようにしてもよい。

＜受信装置＞
以下、受信装置１０の構成について説明する。
受信装置１０において、映像データ受信部１１は、パケット化されネットワークを介して送信装置３０からストリーミング送信（配信）される映像データを受信する。受信データ監視部１２は、受信された映像データの受信総データ量、受信データのビットレート、受信時の伝送エラーの有無等の処理状況（受信状況）を監視する。制御要求送信部１３は、再生開始、一時停止、再生速度指定等の再生制御要求を送信装置３０に対して送信する。

ユーザインタフェース制御部１４は、受信装置１０のユーザの操作を受け、ポインティングデバイスやキーボード等の入力デバイスを介して送信装置３０に再生開始、一時停止、特殊再生等の再生動作の指示を行うためのユーザインタフェースに係る制御を行う。映像情報受信部１５は、送信装置３０から送信される映像コンテンツ中の画面内符号化された画像の画像間隔（フレーム間隔）等の映像情報を受信する。映像情報は、例えば制御要求送信部１３から送信する再生制御要求に対する送信装置３０からの応答である返信データに含まれている。

映像情報記憶部１６は、映像情報受信部１５で受信した映像情報を記憶する。映像情報記憶部１６は、例えば画面内符号化された画像の画像間隔に係る情報を記憶する。映像情報選択部１７は、映像情報記憶部１６に記憶された画像間隔のうちのいずれかを選択する。

映像データ復号化部１８は、映像データ受信部１１で受信された映像データを復号化する。映像データ再生部１９は、映像データ復号化部１８で復号化された映像データに含まれる時刻情報を抽出し、受信された映像データに係る映像を抽出された時刻情報に示されるタイミングで画面に表示する。なお、映像データ復号化部１８及び映像データ再生部１９は、本発明の各実施形態では必須要件ではないが、一般的な映像受信クライアントには通常搭載されることから図示している。

ＣＰＵ（Central Processing Unit）２０は、受信装置１０全体を制御する。ＣＰＵ２０は、例えばメモリや記憶装置等に記憶されたソフトウェア又は外部より供給されるソフトウェアを実行することで、受信装置１０内の各機能部を制御する。ＣＰＵ２０は、例えばソフトウェア（処理プログラム）をＲＯＭ２１等から読み出して実行することで、後述する各実施形態での動作を実現するための制御を行う。
受信装置１０内の各機能部１１、１２、１３、１４、１５、１６、１７、１８、１９、２０は、システムバスを介して互いに通信可能に接続される。

映像データ受信部１１、受信データ監視部１２、制御要求送信部１３、及びユーザインタフェース制御部１４は、変更を必要としないプログラムやパラメータを格納するＲＯＭ（Read Only Memory）２１に実装される。また、映像情報受信部１５、映像情報選択部１７、及び映像データ復号化部１８、映像データ再生部１９も、ＲＯＭ２１に実装される。

映像情報記憶部１６は、変更されるパラメータを保持するＲＡＭ（Random Access Memory）であり、一時記憶２２として実装される。一時記憶２２としては、装置に固定して設置されたハードディスクやメモリカード、あるいは装置から着脱可能なフレキシブルディスク（ＦＤ）やコンパクトディスク（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む。

＜送信装置＞
次に、送信装置３０の構成について説明する。
送信装置３０において、３１はパケット化され送信装置３０からストリーミング送信（配信）される映像コンテンツの映像データである。映像データ送信部３２は、送信装置３０に保存されている映像データ３１及び時刻情報等の再生制御情報を、ネットワークに適合した形式でパケット化し伝送路にストリーミング送信する。制御要求受信部３３は、受信装置１０から送信される再生開始、一時停止、再生速度指定等の再生制御要求を受信する。送信データ監視部３４は、送信された映像データの送信データ量、送信データのビットレート等の処理状況を監視する。

制御要求判断部３５は、制御要求受信部３３で受信された再生制御要求の内容を解釈し、どのような再生及び配信を行うかを判断する。映像情報送信部３６は、映像コンテンツの画面内符号化された画像の画像間隔（フレーム間隔）等の映像情報を受信装置１０に送信する。

映像データ読み出し部３７は、映像データ３１に含まれる映像データ、時刻情報、映像データの符号化形式や画面内符号化されているか否か等の符号化属性といった映像情報を読み出す。さらに、映像データ読み出し部３７は、映像データをパケット化するための情報が映像データ３１に含まれている場合には、その情報を読み出す。送信履歴記憶部３８は、映像データ送信部３２から送信した送信済みの映像データに付随する時刻情報等の履歴を保持する。

映像データ符号化部３９は、送信装置３０に接続される図示されないカメラやテレビ、ビデオ等の映像入力機器から得られる映像信号をデジタル化し符号化する。映像データ記録部４０は、映像データ符号化部３９で符号化された映像データを映像データ３１として記録する。また、映像データ記録部４０は、映像データに加え、その映像データの送信時に使用する補足情報を記録するようにしてもよい。なお、映像データ符号化部３９及び映像データ記録部４０は、本発明の各実施形態では必須要件ではないが、カメラの記録映像を遠隔地からもネットワークで視聴するいわゆるネットワークカメラやカメラサーバ等の製品には通常搭載されることから図示している。

ＣＰＵ（Central Processing Unit）４１は、送信装置３０全体を制御する。ＣＰＵ４１は、例えばメモリや記憶装置等に記憶されたソフトウェア又は外部より供給されるソフトウェアを実行することで、送信装置３０内の各機能部を制御する。ＣＰＵ４１は、例えばソフトウェア（処理プログラム）をＲＯＭ４２等から読み出して実行することで、後述する各実施形態での動作を実現するための制御を行う。
送信装置３０内の各機能部３１、３２、３３、３４、３５、３６、３７、３８、３９、４０、４１は、システムバスを介して互いに通信可能に接続される。

映像データ送信部３２、制御要求受信部３３、送信データ監視部３４、及び制御要求判断部３５は、変更を必要としないプログラムやパラメータを格納するＲＯＭ（Read Only Memory）４２に実装される。また、映像情報送信部３６、映像データ読み出し部３７、及び映像データ符号化部３９、映像データ記録部４０も、ＲＯＭ４２に実装される。

送信履歴記憶部３８は、変更されるパラメータを保持するＲＡＭ（Random Access Memory）であり、一時記憶４３として実装される。一時記憶４３としては、装置に固定して設置されたハードディスクやメモリカード、あるいは装置から着脱可能なフレキシブルディスク（ＦＤ）やコンパクトディスク（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む。また、映像データ３１は、送信装置３０の内部又は送信装置３０がアクセス可能な外部のいずれかの場所にあるものとして、その記録形態は問わないものとする。

なお、本実施形態における受信装置１０及び送信装置３０は、通信プロトコルとしてＲＴＳＰ及びＲＴＰといったインターネットにおけるリアルタイム映像通信プロトコルをサポートするものとする。しかしながら、これに限定されるものではなく、ＲＴＳＰやＲＴＰと同等の目的を持つ他のプロトコルによって実現されてもよい。また、本実施形態の受信装置１０と送信装置３０とは、インターネット等の公衆網又はイーサネット（登録商標）やＩＥＥＥ８０２．１１等の通信網等のネットワークを介して通信を行うものとするが、その他のネットワークにおいて利用されてもよい。

＜ユーザインタフェース＞
次に、本実施形態における受信装置１０にて、再生開始、一時停止、特殊再生等の再生動作の指示を送信装置３０に行うためのユーザインタフェースについて説明する。

図３は、本実施形態におけるユーザインタフェース５０の一例を示す図である。
ユーザインタフェース５０において、５１は映像を表示する表示領域である。表示領域５１には、受信された映像データを映像データ復号化部１８で復号化処理した後に映像データ再生部１９で出力することによって、該映像データに係る映像が表示される。

５２は受信された映像データの再生を開始又は停止させるための再生ボタンである。本実施形態では、再生ボタン５２はトグルスイッチであり、トグル状態によって停止処理も同一のボタンで制御できるものとしているが、再生ボタンと停止ボタンは別のボタンとして設けるようにしてもよい。

５３は映像データを逆方向に高速再生させるための巻き戻しボタンである。５４は映像データを順方向に高速再生させるための早送りボタンである。巻き戻しボタン５３及び早送りボタン５４は、いずれも映像データを逆方向、順方向に高速再生させる機能を提供している。なお、同様に映像データを逆方向、順方向に特殊再生させるコマ送り再生機能、スロー再生機能を同ボタン５３、５４の機能の一部として提供できるようにしてもよいし、又は別のボタンを設けて提供できるようにしてもよい。

また、本実施形態では、ユーザインタフェース５０はボタンを用いて各機能を提供するようにしている。しかし、これに限定されるものではなく、ジョグダイヤルやホイール、レバー、キーパッド、ジョイスティック、シャトルコントローラ等を用いて同等の機能を提供するようにしてもよく、その形状は問わない。

なお、以下の説明において、再生される画像間の時間間隔はｔとして表し、通常再生（通常速度での再生）時のｎ倍速の順方向再生時の再生速度はｎとして表す。すなわち、映像データを順方向に再生する際は（ｎ×ｔ）の間隔の画像が表示される。また、映像データを逆方向に再生する場合には、ｎはマイナスの値をとるものとする。したがって、画像間隔（ｎ×ｔ）は負数となる。また、通常再生時の再生速度ｎは１であるため、スロー再生時の再生速度ｎは１未満の値となる。

（第１の実施形態）
本発明の第１の実施形態について説明する。
以下、ユーザインタフェース５０を介して早送り再生（順方向の高速再生）を行う場合の受信装置１０の処理を、図４を参照し説明する。図４は、第１の実施形態における受信装置１０の処理動作例を示すフローチャートである。図４に示す処理は、ユーザインタフェース５０に対する特定の操作、具体的にはユーザインタフェース５０の早送りボタン５４に入力操作が行われたときに実行される。

図４に示すステップ４０１にて、ＣＰＵ２０は、ユーザインタフェース５０に配置されている早送りボタン５４が押下されているか否かを判断する。その結果、早送りボタン５４が押下されていると判断した場合には、ステップ４０２にて、ＣＰＵ２０は、映像データ再生部１９で処理中の映像データの再生時刻情報を取得し、ステップ４０３へ進む。一方、ステップ４０１において、早送りボタン５４が押下されていないと判断した場合には、図４に示す処理は終了する。

ステップ４０３にて、ＣＰＵ２０は、ステップ４０２において取得された映像データの現在の再生時刻に（再生速度ｎ×画像間の時刻間隔ｔ）を加算して得られる時刻値を、再生開始時刻として設定する。早送り再生の場合には、再生速度ｎは１より大きい値で、典型的には受信装置１０のユーザインタフェース仕様で規定される任意の固定値が使用される。

次に、ステップ４０４にて、受信データ監視部１２は、指示される再生速度で再生を行う場合に受信されるデータ量がシステムの処理能力を超えているかを判断する。具体的には、受信データ監視部１２は、受信されるデータ量が受信装置１０で処理可能なデータ量、又はネットワークで伝送可能なデータ量を超えているか否かを判断する。なお、どのようにして処理能力及び伝送能力の超過を判断するかに関しては、図４に示したフローチャートの処理説明の後に記述する。

ステップ４０４において、指示される再生速度で早送り再生を行う際に受信されるデータ量がシステムの処理能力を超えていると判断されたら、ステップ４０５へ進む。ステップ４０５にて、ＣＰＵ２０は、送信装置３０に対して送信される再生制御要求に、その映像データだけで１画面の映像を復号・表示することが可能な画面内符号化された映像データのみを要求することを示すコマンドを付加する。この再生制御要求に付加するコマンドは、言い換えれば、他画面（他フレーム）の映像データを参照して復号される画面間予測符号化された映像データを送信しない（該映像データの送信を禁止する）よう要求するものである。

前記ステップ４０２〜４０５の処理により、再生開始時刻、及び画面内符号化された映像データのみの要求の要否が設定される。続いて、ステップ４０６にて、ＣＰＵ２０は、制御要求送信部１３に再生制御要求の送信を指示し、送信装置３０に対して映像データを要求する。送信される再生制御要求には、前記処理で設定された再生開始時刻、再生速度ｎ、及び画面内符号化された映像データのみの要求の要否を示す情報を含む。

上述のようにして受信装置１０から送信された再生制御要求に対する応答として送信装置３０から順次送信される再生開始時刻の映像データは、受信装置１０の映像データ受信部１１で受信され、映像データ復号化部１８で復号化される。そして、復号化された映像データは映像データ再生部１９に渡され、再生開始時刻に対応する映像が図３に示した表示領域５１に表示される。

なお、再生制御要求によって画面内符号化された映像データのみを要求した場合には、送信装置３０からは映像データとして面内符号化された映像データのみが順次送信される。また、再生制御要求を発行する前にすでに受信装置１０で受信され、あるいは復号化されて装置内に保持されている映像データは、再生制御要求を発行する前後のタイミングでクリアしてもよい。

以降、ステップ４０１の処理に戻り、ユーザインタフェース５０の早送りボタン５４が押下されている間は、図４に示した処理が継続して実行される。

次に、図４に示したフローチャートのステップ４０４において、受信データ監視部１２が、受信されるデータ量が受信装置１０で処理可能な能力及びネットワークで伝送可能な能力を超えているかを判断する手法の具体例を、図５及び図６を参照して説明する。

図５は、受信装置１０の映像データ受信部１１で受信された映像データが、映像データ復号化部１８及び映像データ再生部１９に受け渡される間に介在するバッファ６０を示す図である。一般的に、受信装置１０の一時記憶２２には、復号化処理や再生処理を行う機能部に渡すまでの間、受信されたデータを一時的に記憶するためのバッファが備えられている。復号化処理及び再生処理に要する処理時間がゼロで、かつ映像データの伝送に遅延やゆらぎが存在しない理想的な環境下においては、このようなバッファは不要であるが、現実的にはそのような理想的な環境はありえない。特に、インターネット等の公衆網では伝送帯域幅が不安定であるため、伝送のゆらぎが再生動作に大きな影響を及ぼす。したがって、伝送ゆらぎなどの影響を吸収し正常な再生動作を実現できるようにするため、一般的には受信されたデータを一時的に記憶するバッファが用いられる。

図５に示すバッファ６０は、ＦＩＦＯ（First In First Out）の構造を持つ。映像データ受信部１１で受信されるデータは、順次バッファ６０に格納され、格納された順に従ってバッファ６０内のデータが映像データ復号化部１８及び映像データ再生部１９に順次渡される。ここで、バッファ６０に記憶されている現在のデータ量をＮ、受信可能なデータ上限量（バッファ６０に格納可能なデータ上限量であり、ここではバッファ６０の最大容量とする）をＸとする。通常速度での再生時（再生速度ｎ＝１）には、Ｎ＜Ｘの状態が維持されていても、再生速度ｎ（ｎ＞１）の早送り再生によってデータの流量がｎ倍になると、Ｎ＜Ｘの関係が保てず、いわゆる「バッファオーバーフロー」の現象が起こり得る。

そこで、図４に示したステップ４０４において、受信データ監視部１２は、バッファ６０の現在のデータ量Ｎ及びデータ上限量Ｘの値を監視し、Ｎ≧Ｘの状態になった場合にはデータの伝送量に対して復号化処理や再生処理が追いついていないと判断する。そして、ＣＰＵ２０は、受信データ監視部１２での判断結果を受けて、後続の処理で画面内符号化された映像データのみの要求を発行する。また、このタイミングでバッファ６０に格納されているデータをすべて廃棄するようにしてもよい。

なお、受信可能なデータ上限量Ｘは、必ずしもバッファ６０の最大容量と等しくなくてもよく、バッファ６０の最大容量より小さい値を受信可能なデータ上限量Ｘとしてもよい。受信可能なデータ上限量Ｘがバッファ６０の最大容量より小さければ、バッファオーバーフローが発生する可能性が抑えられるので、受信済みの映像データを破棄することなく復号化処理や再生処理を行えるようになる。これにより、配信サーバである送信装置３０に対して画面内符号化された映像データのみの要求を発行してから映像データが送られてくるまでの間の再生が停止し映像データの待ち状態になる時間を短縮し、再生時の違和感を緩和することができる。

また、受信可能なデータ上限量Ｘは、受信装置１０の映像データ復号化部１８や映像データ再生部１９で処理可能な、言い換えれば受信装置１０で受信可能な単位時間当たりの最大ビットレートとして表すこともできる。この場合には、受信データ監視部１２は、受信可能な単位時間当たりのビットレートＮが最大ビットレートＸを上回ったときに、受信装置１０での復号化処理や再生処理が追いついていないと判断することもできる。

以上のように、受信装置１０の受信データ監視部１２に上述したようなバッファ監視機構を組み入れることにより、クライアント端末（視聴端末）である受信装置１０の処理能力を超えているか否かを判定することが可能である。

しかしながら、受信装置１０及び送信装置３０間で映像データ等を送受信するネットワークの伝送能力を超えたトラフィックが生じている場合には、ネットワーク中に流れるパケットが輻輳や衝突により消失することがある。特に、ＵＤＰデータグラムパケット等のように消失したパケットの再送が行われない伝送方式の場合には、消失したパケットは、失われたままであり受信装置１０側に届くことがない。そのため、受信装置１０のバッファに蓄積されたデータ量は正常に見えても、実際にはネットワークの伝送能力を超えているためにパケットの消失が発生している可能性がある。

ＲＴＰには、このようなパケットの消失を検出するための仕組みが用意されている。図６は、ＲＴＰのパケット・ヘッダーを示す概略図である。図６に示すsequence numberフィールド６１には、送信される毎に１ずつ加算される連続番号が設定されるようにＲＴＰでは規定されている。

sequence numberフィールド６１を用いたパケットの消失検出の一例を、図７を参照して説明する。図７に示す例では、送信装置３０からパケット７１、７２、７３、７４、７５が順に送信され、パケット７１〜７５のsequence numberフィールド６１にはそれぞれ値“１”、“２”、“３”、“４”、“５”が付与されているものとする。また、送信装置３０から受信装置１０への伝送途中で、パケット７３が消失したものとする。

受信装置１０は、到着したパケットのsequence numberフィールド６１の値が、正しく１ずつ加算されているかどうかを確認する。図７の例では、パケット７４を受信するとsequence numberフィールド６１の値“３”が付与されたパケット７３が到着していないこと、すなわちsequence numberフィールド６１に付与された値が不連続になったことが検出される。受信装置１０は、このように受信したパケットのsequence numberフィールド６１に付与された値が不連続であることで、ネットワークの伝送能力を超えているような状態であることを検出することができる。このような方法は、ＲＴＰに限らず、同様の仕組みを提供する伝送方式に対しても適用可能である。

上述のようなネットワークの伝送能力についての判定処理を、図４に示したステップ４０４において受信バッファ管理（上述した受信バッファの監視機構）の代わりに、あるいはそれと併用して用いることも可能である。

図８は、図４に示したフローチャートの処理が実行された場合の送信装置３０及び受信装置１０間で行われるＲＴＳＰの通信シーケンス（プロトコルシーケンス）の一例を示す図である。すなわち、図８においては、映像コンテンツを通常再生で視聴中にユーザインタフェース５０の早送りボタン５４に特定の入力操作が行われて早送り再生（順方向の高速再生）を行う場合の通信シーケンスを示している。

図８において、「Ｃ→Ｓ」は、クライアント端末である受信装置１０の制御要求送信部１３からサーバである送信装置３０の制御要求受信部３３に対して送信される、再生制御要求を含むＲＴＳＰメッセージであることを示している。また、「Ｓ→Ｃ」は、サーバである送信装置３０の映像情報送信部３６から送信され、クライアント端末である受信装置１０の映像情報受信部１５で受信される、再生制御要求の応答及び映像情報を含むＲＴＳＰメッセージであることを示している。

図８に示す本実施形態における送信装置３０及び受信装置１０間の通信シーケンスは、図１に示した従来の通信シーケンスとほぼ同様であるが、早送り再生を行うために再度送信するPLAY（再生）コマンドの一部が異なる。図８に示す通信シーケンスでは、早送り再生を行うためのPLAYコマンド中に、x-Intra-Onlyフィールド８１が追加されている。

x-Intra-Onlyフィールド８１は、受信装置１０が画面内符号化された映像データのみの要求を含むかどうかを示すもので、値が真（true）である場合に画面内符号化された映像データのみの要求を行っているものとしている。なお、図８に示したx-Intra-Onlyフィールド８１は一例であり、画面内符号化された映像データのみを要求することを意味する内容が再生制御要求に含まれており、通信プロトコル仕様に倣っているものであれば、どのような形式であってもよい。

以上、第１の実施形態によれば、受信装置１０は、指示する再生速度で早送り再生を行う際に受信されるデータ量がシステムの処理能力を超えると判断された場合には、送信装置３０に画面内符号化された映像データのみを要求する再生制御要求を送信する。これにより、映像の乱れがない早送り再生及び巻き戻し再生を含む特殊再生機能を提供することができる。また、早送り再生や巻き戻し再生などの高速再生要求を行った場合にも、受信装置１０は、処理しきれないデータを受信することなく、必要な映像データのみを要求できる。したがって、不要な映像データ等を通信することによる伝送路のトラフィックの増大を抑制することが可能になり、受信装置１０の処理負荷も軽減できる。また、受信装置１０に高速再生を実現するための大容量の記憶装置を新たに設ける必要もなく、受信装置１０に係るコストの増大も抑制することができる。

なお、上述した第１の実施形態における動作では、映像情報記憶部１６及び映像情報選択部１７が有する機能は必須の機能ではないので、第１の実施形態における受信装置１０は、映像情報記憶部１６及び映像情報選択部１７を備えていなくともよい。また、同様に送信履歴記憶部３８が有する機能は必須の機能ではないので、第１の実施形態における送信装置３０は、送信履歴記憶部３８を備えていなくともよい。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
以下、受信装置１０の操作者がユーザインタフェース５０から早送り再生（順方向の高速再生）を指示し、それを受けて受信装置１０から早送り再生に係る再生制御要求が送られてきた場合の送信装置３０の処理を、図９を参照し説明する。図９は、第２の実施形態における送信装置３０の処理動作例を示すフローチャートである。図９に示す処理は、ユーザインタフェース５０に対する特定の操作、具体的にはユーザインタフェース５０の早送りボタン５４に入力操作が行われたときに実行される。

図９に示すステップ９０１にて、送信装置３０の制御要求判断部３５は、制御要求受信部３３で受信された受信装置１０からの再生制御要求に、早送り再生を指示する要求が含まれているか否かを判断する。本実施形態では、PLAYコマンド中のScale（又はSpeed）フィールドに１より大きい値が設定されている場合には、早送り再生が要求されているものとみなす。ステップ９０１での判断の結果、受信された再生制御要求では早送り再生が要求されていないと判断した場合には、図９に示す処理は終了する。

一方、ステップ９０１での判断の結果、送信装置３０の制御要求判断部３５が、再生制御要求により受信装置１０から早送り再生が要求されていると判断した場合には、ステップ９０２へ進む。ステップ９０２にて、ＣＰＵ４１は、映像データ読み出し部３７により読み出される現在処理中の映像データの再生時刻情報を取得し、その再生時刻に（再生速度ｎ×画像間の時刻間隔ｔ）を加算して得られる時刻値を、再生開始時刻として設定する。本実施形態では、再生速度ｎは受信装置１０から送信されるPLAYコマンド中のScale（又はSpeed）フィールドに設定されている値が使用されるものとする。

次に、ステップ９０３にて、送信装置３０は、再生速度ｎで再生を行うために送信するデータ量が受信装置１０又はネットワークの能力を超えているかを判断する。具体的には、受信装置１０に対して送信するデータ量が受信装置１０で処理可能なデータ量、又はネットワークで伝送可能なデータ量を超えているか否かを判断する。なお、送信装置３０のどの機能部が、どのような手段で処理能力及び伝送能力の超過を判断するかについては、図９に示したフローチャートの処理説明の後に、いくつかの具体例を挙げて説明するので、ここでは詳細な説明は省略する。

ステップ９０３において、再生速度ｎでの早送り再生を行わせる際に送信するデータ量が受信装置１０又はネットワークの能力を超えていると判断された場合には、ステップ９０４へ進む。ステップ９０４にて、ＣＰＵ４１は、ステップ９０２において得られた再生開始時刻に、再生方向に沿って最も近接する時刻位置の画面内符号化された映像データ及びその再生時刻を映像データ読み出し部３７等を介して取得する。本実施形態の場合には順方向の再生であるので、取得される映像データは再生開始時刻以降の映像データである。

映像データが画面内符号化されているかどうかは、その映像の符号化形式によって異なる。Ｍｏｔｉｏｎ−ＪＰＥＧ又はＭｏｔｉｏｎ−ＪＰＥＧ２０００のような映像データが各フレーム毎に独立して符号化される形式の場合には、すべての映像データが画面内符号化されているものとして、取得された映像データをそのまま送信データとして使用できる。

一方、ＭＰＥＧ、Ｈ.２６４、ＶＣ−１等の前後のフレームとの差分情報を用いたフレーム間予測を利用する符号化形式の場合には、取得された映像データが必ずしも画面内符号化された映像データであるとは限らない。そのため、処理対象の映像データ中に画面内符号化されていない映像データ（画面間予測符号化された映像データ）が含まれる場合の送信装置３０の動作としては、以下の二通りの処理が考えられる。

第１の方法は、映像データ読み出し部３７を介して、ステップ９０２で得られた再生開始時刻に再生方向に沿って最も近接する時刻位置の画面内符号化された映像データを探索して取得する方法である。第２の方法は、映像データ符号化部３９で処理対象の映像データを参照されているフレーム情報を基に画面内符号化された映像データとして再符号化する方法である。

第１の方法は、新たな符号化処理を必要としないために処理負荷が小さいが、再生速度と画面内符号化された映像データの間隔が大きく異なる場合には、要求された再生速度と実際の再生速度との差異のため再生される映像に違和感が生じる可能性がある。一方、第２の方法は、再生動作は自然だが、符号化処理を要するために処理負荷が増加する。第１の方法及び第２の方法のどちらを用いるかは、システムに応じて任意に選択すればよく、いずれか一方のみを用いるようにしてもよいし、送信装置３０のＣＰＵ負荷や接続数等の状況に応じて両方を適応的に切り替えて用いるようにしてもよい。

次に、ステップ９０５にて、ＣＰＵ４１は、ステップ９０４において取得された画面内符号化された映像データの再生時刻を再生開始時刻として設定する。

一方、ステップ９０３において、送信するデータ量が受信装置１０又はネットワークの能力を超えていないと判断された場合には、ステップ９０６へ進む。ステップ９０６にて、ＣＰＵ４１は、映像データ読み出し部３７を介して、ステップ９０２において得られた再生開始時刻に対応する映像データを抽出するのみで、再生開始時刻は変更しない。

上述のようにして早送り再生時に表示される映像データと再生開始時刻が抽出される。ここで注意しなければならない点は、ここで抽出された再生開始時刻は、対象としている映像データの時間軸に沿った再生開始時刻であるという点である。受信装置１０がこの映像データの時間軸に従って再生を行っている場合、早送りであることによって得られた将来の時刻は、受信装置１０が通常再生を行っていることから、このままの状態で送出すると高速再生にはならない。単に受信された映像をその指定された時刻まで待って再生することになる。そこで、ステップ９０７にて、ＣＰＵ４１は、（現在の再生時刻＋ｔ）の値を送信時の新たな再生開始時刻として設定する。すなわち、早送り動作を通常再生であるかのように取り扱うものである。この処理によって、次に再生される映像データがｎ倍速再生時に次に再生される映像データにすることができる。

上述したようにして送信する映像データ及び再生開始時刻が設定されたら、送信装置３０のＣＰＵ４１は、映像データ及び再生開始時刻をパケット化して映像データ送信部３２から順次送信する。映像データ送信部３２から送信されたデータは、受信装置１０で受信されて復号化処理され、図３に示した表示領域５１に再生表示される。

以降、ステップ９０１の処理に戻り、再生制御要求により受信装置１０から早送り再生が要求されている間は、図９に示した処理が継続して実行される。

なお、ここまでの説明において、受信装置１０は、早送り動作に関して、便宜上第１の実施形態で説明したような再生速度の変更を行わないものと仮定してきた。しかしながら、本実施形態と第１の実施形態は複合的に動作可能であり、ステップ９０７の処理が不要となる場合もある。このような例は説明が複雑となるため、その詳細動作の説明は省略する。送信装置３０と受信装置１０の間の連携動作を行う例のひとつは、第３の実施形態において説明する。

次に、図９に示したフローチャートのステップ９０３において、送信装置３０のどの機能部が、どのようにして送信データ量が受信装置１０で処理可能な能力又はネットワークで伝送可能な能力を超えているかを判断する手法の具体例を説明する。

まず、第１の判断方法は、受信装置１０から明示的に画面内符号化された映像データのみが要求されているか否かを判断する方法である。明示的な画面内符号化された映像データのみの要求の例としては、第１の実施形態において図８に示したＲＴＳＰシーケンスのx-Intra-Onlyフィールド８１のようなx-Intra-Onlyコマンドがある。送信装置３０の制御要求判断部３５は、制御要求受信部３３で受信された再生制御要求に画面内符号化された映像データのみの要求を示す内容が含まれているか否かを調査し、それが含まれていれば受信装置１０の処理能力を超えていると判断する。

また、第２の判断方法は、受信装置１０から暗黙的に通知されるネットワークの伝送状態から、ネットワークの伝送能力を超過しているかを判断する方法である。映像データの伝送プロトコルにＲＴＰを用いる場合、ＲＴＰに付随してネットワークの状態を報告するためのＲＴＣＰ（ＲＴＰと同じくＲＦＣ３５５０で定義されているRTP Control Protocol）も併用される。

図１０は、ＲＴＣＰにおいて受信側装置が受信状況のフィードバックのために、送信側装置に対して定期的に送信するＲＲ（Receiver Report）パケットの構成を示す図である。ＲＲパケット中のcumulative number of packets lostフィールド１００には、前回のＲＲパケットの送信時から今回のＲＲパケットの送信時までに検出された消失パケットの数が設定される。ネットワーク上での消失パケットの数の情報を含むＲＲパケットを送信装置３０に対して送信することで、ネットワークの伝送状態を受信装置１０から送信装置３０に暗黙的に通知することができる。送信装置３０の制御要求判断部３５は、受信した受信装置１０からのＲＲパケットの内容を調査して、消失パケットの数が閾値として設定されている数を超える場合にはネットワークの伝送能力を超えていると判断することができる。

また、第３の判断方法は、送信装置３０の送信データ監視部３４で、映像データ送信部３２から送出される映像データのビットレートを監視し、受信装置１０で受信可能なビットレートを超過した場合に受信装置１０の処理能力を超えたと判断する方法である。例えば、受信装置１０で受信可能なビットレートは、第１の実施形態において図８に示したＲＴＳＰシーケンス中のBandwidthフィールド８２により送信装置３０に対して前もって通知することができる。この場合、送信データ監視部３４は、１秒あたりの送信ビットレートがBandwidthフィールド８２で示される値を超過した時点で受信装置１０の受信能力を超過したとみなすことができる。

第２の実施形態によれば、送信装置３０は、再生速度ｎでの高速再生要求を受けた場合に、送信データ量が受信装置１０又はネットワークの能力を超えていると判断された場合には、画面内符号化された映像データのみを送信する。これにより、受信装置１０やネットワークの負荷を高めることなく早送り再生や巻き戻し再生を含む特殊再生処理を行うことができる。

また、伝送状況や受信状況に基づいて、送信データ量が受信装置１０又はネットワークの能力を超えているか判断するようにした場合には、受信装置に明示的に画面内符号化された映像データのみを要求する特別なコマンドを発行するような拡張を必要としない。したがって、一般的な受信装置１０に対しても同等の機能を提供することができる。

なお、上述した第２の実施形態における動作では、映像情報記憶部１６及び映像情報選択部１７が有する機能は必須の機能ではないので、第２の実施形態における受信装置１０は、映像情報記憶部１６及び映像情報選択部１７を備えていなくともよい。また、同様に送信履歴記憶部３８が有する機能は必須の機能ではないので、第２の実施形態における送信装置３０は、送信履歴記憶部３８を備えていなくともよい。

以上、第１及び第２の実施形態によれば、コストを増大させることなく許容される負荷に応じて、早送り再生及び巻き戻し再生を含む特殊再生機能を提供する通信システムを構築することができる。以下では、本発明の実施形態に係る通信システムにおいて、より改善・発展を図ることが可能であると思われる事項の解決策を、個別の実施の形態として説明する。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。
上述した第１及び第２の実施形態において、受信装置１０が要求する再生速度は、必ずしも送信装置３０から送られる映像データの再生速度と一致しているとは限らない。とりわけ、画面間予測符号化された映像データを含み、かつ、指定された再生開始時刻から再生方向に沿って次の画面内符号化された映像データを探索する場合には、画面内符号化された映像データの間隔が長いほど再生速度の不一致の影響は顕著に現れる。
そこで、以下に説明する第３の実施形態では、送信装置３０でサポートする再生速度を受信装置１０に予め通知しておき、受信装置１０はサポートされている再生速度のみを要求するようにする。

第３の実施形態において、送信装置３０のＣＰＵ４１は、映像データ読み出し部３７により得られる情報を基に、画面内符号化された映像データがどれだけの間隔（フレーム間隔、画面間隔）で挿入されているかを検出し、指定可能な再生速度を求める。例えば、５フレーム毎に画面内符号化されている映像データが存在している場合には、５倍速及びその倍数の速度での高速再生が可能である。このようにして得られた指定可能な再生速度を示す情報を含む映像情報は、送信装置３０の映像情報送信部３６から受信装置１０に対して送信される。これにより、送信装置３０でサポートされる再生速度を受信装置１０に通知する。

図１１は、第３の実施形態における送信装置３０及び受信装置１０間で行われるＲＴＳＰの通信シーケンスの一例を示す図である。図１１に示す第３の実施形態における通信シーケンスは、図８に示した第１の実施形態における通信シーケンスとほぼ同様であるが、受信装置１０からのSETUP（配信設定）コマンドに対する送信装置３０の応答（設定情報）の一部が異なる。

図１１に示す例では、受信したSETUPコマンドに対する送信装置３０の応答中にx-AvailSpeedフィールド１１１が追加されている。送信装置３０は、サポートする再生速度をx-AvailSpeedフィールド１１１に設定して送信することにより、サポートされる再生速度を受信装置１０に通知する。図１１に示す例では、サポートされる再生速度を「；」で区切って複数設定することにより、複数の再生速度をサポートすることも通知している。なお、図１１に示した記法はあくまでも一例であり、同等の意味を持つ内容を通知することが可能であれば、その文法はいかなるものであってもよい。

また、上述した説明では、送信装置３０が画面内符号化された映像データの間隔から指定可能な再生速度を求めて通知するようにしている。しかしながら、例えば受信装置１０が再生速度を算出可能であれば、画面内符号化された映像データの間隔、単位時間当たりの画面内符号化された映像データの数など、送信装置３０から受信装置１０に通知する情報は必ずしも指定可能な再生速度でなくてもよい。また、上述した例では、SETUPコマンドに対する送信装置３０の応答によって指定可能な再生速度を通知するようにしているが、これに限定されるものではなく、受信装置１０で映像データの再生を開始する前の任意のタイミングで通知されていればよい。

上述のようにして送信された送信装置３０でサポートされる再生速度を示す情報を含む映像情報を受信装置１０の映像情報受信部１５で受信すると、ＣＰＵ２０は、受信した情報を映像情報記憶部１６に保持しておく。そして、図３に示した受信装置１０のユーザインタフェース５０の早送りボタン５４（又は巻き戻しボタン５３）が押下されると、受信装置１０のＣＰＵ２０は、行われた入力操作に対応する再生速度を選択するよう映像情報選択部１７に指示する。指示を受けた映像情報選択部１７は、ユーザインタフェース５０から入力された操作に対応する再生速度を、映像情報記憶部１６に保持されている映像情報から抽出する。そして、ＣＰＵ２０は、映像情報選択部１７により抽出・選択された再生速度を、映像の再生速度ｎとして設定する。再生速度ｎを設定した後の処理動作は、上述した第１の実施形態における図４に示した処理動作と同様である。

また、受信装置１０のユーザインタフェース５０は、操作者による入力操作に応じて複数の再生速度を切り替えられるようになっていてもよい。例えば、図３に示したユーザインタフェース５０の例では、早送りボタン５４が一回押されると５倍速、さらに一回押されると１０倍速というように早送りボタン５４に対する操作に応じて複数の再生速度を切り替えるようにしてもよい。その他、ボタンが押されている時間の長さ（強さであってもよい）、ボタン以外のインタフェースであれば回転数や角度、傾き等から、送信装置３０でサポートされる再生速度から任意の再生速度を映像情報選択部１７により選択して要求することも可能である。さらに、操作者が再生速度を容易に認識できるように、選択された再生速度がユーザインタフェース５０の表示領域５１に表示されればより好ましい。

第３の実施形態によれば、通信システムを構成する受信装置１０が要求する再生速度と、送信装置３０でサポートできる再生速度との不一致がなくなり、操作時に要求した速度と実際に再生される速度とが異なることによる違和感を解消することができる。

（第４の実施形態）
次に、本発明の第４の実施形態について説明する。
第４の実施形態は、受信装置１０が要求する再生速度と送信装置３０から送られる映像データの再生速度との不一致が発生し得る場合に用いて好適なものであり、例えば上述した第３の実施形態を適用できない場合に用いてより好適である。

図１２に示すように、１５フレーム毎に画面内符号化された映像データ（Ｉピクチャ）１２１及び１２４が生成され、両者の間に存在するフレームは画面間予測符号化された映像データ（Ｐピクチャ）であるとする。このように画面間予測符号化された映像データを含み、かつ、高速再生の要求時に送信装置が再符号化は行わずに、再生方向に沿って最も近接する画面内符号化された映像データを探索する場合には、送信装置でサポートされる再生速度は１５倍速となる。

ここで、受信装置が送信装置でサポートされる再生速度を受け付けることができない場合には、送信装置は受信装置から指示される任意の再生速度に従わなければならない。図１２に示す例において、受信装置から要求される再生速度が５倍速であるとすると、再生されるべき映像データは１２１、１２２、１２３、１２４となる。しかし、映像データ１２２及び１２３は、画面内符号化された映像データではなく、画面間予測符号化された映像データである。したがって、受信装置から要求される再生速度が５倍速であった場合には、映像データ１２１、１２４、１２４、１２４というように送信装置から受信装置に映像データが送信されることとなる。

このように、受信装置が要求する再生速度と、映像データの画面内符号化された映像データの間隔（送信装置でサポートされる再生速度）とが一致しない場合には、送信装置から受信装置に同じ映像データを複数回送ることがある。これらの重複した映像データは、同じ再生時間の同じ映像を表しているため、再生動作に異常が見られることはない。しかし、同じデータを重複して送信するのは明らかに無駄であり、ネットワークや受信装置の記憶装置に余分な負荷を与えることになる。

上述した課題を解決するための第４の実施形態における送信装置３０の処理例を、図１３を参照し説明する。図１３は、第４の実施形態における送信装置３０の処理動作例を示すフローチャートであり、図９に示した第２の実施形態における送信装置３０の処理に映像データの重複送信を回避するための処理を加えたものである。

図１３において、ステップ１３０１〜１３０６、及び１３０９での処理は、図９に示したステップ９０１〜９０６、及び９０７での処理と同じであるので、説明は省略する。
ステップ１３０７にて、送信装置３０のＣＰＵ４１は、それ以前の処理で得られた再生開始時刻が、送信された映像データの送信履歴を保持する送信履歴記憶部３８に存在するか否かを判断する。

判断の結果、送信しようとしている映像データの再生開始時刻が送信履歴記憶部３８の送信履歴に存在する場合には、その映像データは送信済みであるため、ＣＰＵ４１は、次の画面内符号化された映像データを取得するためにステップ１３０２の処理に戻る。一方、送信しようとしている映像データの再生開始時刻が送信履歴に存在しない場合には、ステップ１３０８にて、その時刻を送信履歴記憶部３８に登録した後、ステップ１３０９の処理を実行して図１３に示す処理を終了する。

前記処理で選択された再生開始時刻の映像データは、後続の処理で映像データ送信部３２から受信装置１０に送信される。

第４の実施形態によれば、送信済みの映像データの履歴を送信履歴記憶部３８により管理することで、送信済みの映像データを再度送信することを防止することができる。これにより、不必要な映像データを送信することによるネットワークや受信装置１０の負荷を高めることなく、早送り再生及び巻き戻し再生を含む特殊再生処理を実現することができる。

（第５の実施形態）
次に、本発明の第５の実施形態について説明する。
上述した各実施形態では、ＲＴＳＰのScale（又はSpeed）フィールドなどの手段によって、送信装置３０に対して任意の再生速度を推定することが可能であるということを前提に説明した。しかし、送信装置３０が再生速度の指定を受け付けない場合には、受信装置１０から再生速度を指定しても、その再生速度での映像データの送信は行われない。

そこで、第５の実施形態では、送信装置３０が再生速度の指定を受け付けない場合でも特殊再生を可能にするための方法を説明する。
まず、第５の実施形態における受信装置１０の基本的な処理動作は、図４に示した第１の実施形態における受信装置１０の処理動作例と同じである。ただし、本実施形態においては、送信装置３０に対して再生制御要求を発行する際、再生終了時刻に再生開始時刻と同じ時刻値を設定して再生制御要求を送信するようにする。すなわち、再生開始時刻の映像データを動画像ではなく、静止画像として再生制御要求を発行するようにする。

そして、ユーザインタフェース５０に対する操作が継続している間は、再生開始時刻を移動させながら連続して、再生開始時刻及び再生終了時刻に同時刻が設定された再生制御要求を発行するようにする。このような処理を行うことで、再生開始時刻に応じた静止画像が連続的に再生されることになり、結果的に特殊再生と同じ再生効果を得ることが可能になる。

図１４は、第５の実施形態における送信装置３０及び受信装置１０間で行われるＲＴＳＰの通信シーケンスの一例を示す図である。なお、再生開始までの流れは、図８に示した第１の実施形態における通信シーケンスと同じであるため、図１４に示す通信シーケンスでは省略している。

図１４には、ＲＴＳＰメッセージのRangeフィールド１４１、１４２、１４３、１４４に、それぞれ再生開始時刻と同じ時刻の再生終了時刻が設定され、PLAY（再生）コマンドが０．５秒毎に連続して発行されている様子が示されている。また、PLAYコマンドにScaleフィールドは存在していない。

以上のように、再生開始時刻と同じ時刻の再生終了時刻が設定された再生制御要求を、画面内符号化された映像データの要求として送信装置３０に送信することも可能である。本実施形態によれば、送信装置３０に任意の再生速度での映像データの配信機能が実装されていないか、又は何らかの理由により実装が困難である場合にも、受信装置１０側の制御のみで特殊再生処理を実現することが可能である。

（第６の実施形態）
次に、本発明の第６の実施形態について説明する。
上述した各実施形態では、特殊再生時に要求・送信される映像データは再生方向に近接する画面内符号化された映像データであるとしてきたが、これに限らず、処理対象は再生方向に近接する「シーンの先頭の」画面内符号化された映像データとすることもできる。

図１５は、映像データ３１がシーン情報を保持している場合の一般的なデータ構成を示す図である。映像データが複数のシーンで構成されている場合には、映像データ３１は、典型的にはインデックスデータ１５１と映像符号化データ１５２とを有する。映像符号化データ１５２は、各シーン毎に物理的又は論理的に分割された符号化された映像データ群からなる。インデックスデータ１５１は、各シーンの先頭の位置情報を保持するデータである。
インデックスデータ１５１と映像符号化データ１５２は、同一のデータファイルなどに一体化して保持されるか、物理的又は論理的に分離した形態で保持される。また、両者は互いにインターリーブされた形式で記録されるような形態も考えられる。このようなシーン情報の典型的な例は、ＤＶＤにおける「チャプター」などが考えられる。ＤＶＤ、Ｂｌｕ−ｒａｙＤｉｓｃやＨＤＤＶＤの場合、映像データはＭＰＥＧ／Ｈ．２６４等の画面間予測符号化された符号化データとして記録され、通常はシーンの先頭は画面内符号化された映像データであるため、本実施形態の適用例としては好適である。

なお、送信装置３０は、受信装置１０から特殊再生を示す再生制御要求を受け取ったら、再生制御要求を受信した回数や要求されている再生速度などの要素に基づいて、再生方向に対して近接するシーンを探索し、順次送信するようにしてもよい。

なお、上述した各実施形態では、特殊再生の一つとして早送り再生を行う場合を一例として説明したが、巻き戻し再生を行う場合も再生方向が逆方向となるだけで同様に処理を行うようにすればよい。また、上述した各実施形態は、それぞれが独立して実現されるものに限らず、適宜、各実施形態を任意に組み合わせて行うようにしてもよい。

（本発明の他の実施形態）
上述した実施形態の機能を実現するべく各種のデバイスを動作させるように、該各種デバイスと接続された装置又はシステム内のコンピュータ（ＣＰＵ又はＭＰＵ）に対し、前記実施形態の機能を実現するためのソフトウェアのプログラムを供給する。そして、そのシステム又は装置のコンピュータに格納されたプログラムに従って前記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。
また、この場合、前記ソフトウェアのプログラム自体が上述した実施形態の機能を実現することになり、そのプログラム自体は本発明を構成する。また、そのプログラムをコンピュータに供給するための手段、例えばかかるプログラムを格納した記録媒体は本発明を構成する。かかるプログラムを記憶する記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
また、供給されたプログラムがコンピュータにて稼働しているオペレーティングシステム又は他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムは本発明の実施形態に含まれることは言うまでもない。
さらに、供給されたプログラムがコンピュータに係る機能拡張ボードや機能拡張ユニットに備わるメモリに格納された後、そのプログラムの指示に基づいてその機能拡張ボード等に備わるＣＰＵ等が実際の処理の一部又は全部を行う。その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

なお、前記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

従来の映像配信システムのＲＴＳＰの通信シーケンスを示す図である。本発明の実施形態に係る通信システムの構成例を示す図である。本実施形態におけるユーザインタフェースの一例を示す図である。第１の実施形態における受信装置の動作例を示すフローチャートである。受信装置が有するバッファを説明するための図である。ＲＴＰのパケット・ヘッダーの構成を示す図である。ＲＴＰでのパケット消失検出方法の一例を説明するための図である。第１の実施形態における送信装置及び受信装置間のＲＴＳＰの通信シーケンスの一例を示す図である。第２の実施形態における送信装置の動作例を示すフローチャートである。ＲＴＣＰのＲＲパケットの構成を示す図である。第３の実施形態における送信装置及び受信装置間のＲＴＳＰの通信シーケンスの一例を示す図である。受信装置が要求する再生速度と送信装置でサポートされる再生速度とが不一致の場合を説明するための図である。第４の実施形態における送信装置の動作例を示すフローチャートである。第５の実施形態における送信装置及び受信装置間のＲＴＳＰの通信シーケンスの一例を示す図である。インデックスデータ及び映像符号化データから構成される映像データの一例を示す図である。

符号の説明

１０受信装置
１１映像データ受信部
１２受信データ監視部
１３制御要求送信部
１４ユーザインタフェース制御部
１５映像情報受信部
１６映像情報記憶部
１７映像情報選択部
１８映像データ復号化部
１９映像データ再生部
２０ＣＰＵ
３０送信装置
３１映像データ
３２映像データ送信部
３３制御要求受信部
３４送信データ監視部
３５制御要求判断部
３６映像情報送信部
３７映像データ読み出し部
３８送信履歴記憶部
３９映像データ符号化部
４０映像データ記録部
４１ＣＰＵ

Claims

伝送路を介して送信装置からストリーミング送信される映像データを受信する受信装置の通信方法であって、
受信手段が、前記映像データを受信する受信工程と、
記憶手段が、受信した映像データを記憶する記憶工程と、
監視手段が、前記記憶手段に記憶されている現在の映像データの量を監視する監視工程と、
前記記憶手段に記憶されている現在の映像データの量が前記記憶手段に記憶できる映像データの上限量を超えた場合に、画面内符号化された映像データの要求と前記映像データの再生速度とを含む再生制御要求を、送信手段が前記送信装置に送信する送信工程と、
再生手段が、前記受信手段が受信した映像データに対応するフレームを再生する再生工程とを有し、
前記再生制御要求に前記画面内符号化された映像データの要求が含まれ、かつ、前記再生速度に応じたフレーム間隔よりも、前記送信装置に保持され画面内符号化された第１のフレームから前記第１のフレームの次に画面内符号化された第２のフレームまでのフレーム間隔が長い場合に、前記受信工程において、前記第１のフレームから前記再生速度に応じたフレーム間隔だけ再生順序が後であり前記第２のフレームよりも前である第３のフレームにかえて前記第２のフレームを前記受信手段が受信するか、または、前記第３のフレームを画面内符号化した第４のフレームを前記第３のフレームにかえて前記受信手段が受信するかを、前記送信装置に接続された受信装置の数に応じて切り替えて前記映像データを受信し、
前記再生工程において、前記受信工程において前記第２のフレームを受信した場合には前記第１のフレームを再生した後、前記第１のフレームから前記再生速度に応じたフレーム間隔だけ再生順序が後の前記第３のフレームにかえて前記第２のフレームを前記再生手段が再生し、前記受信工程において前記第４のフレームを受信した場合には前記第３のフレームにかえて前記第４のフレームを前記再生手段が再生することを特徴とする通信方法。
前記受信工程において、前記再生制御要求に前記画面内符号化された映像データの要求が含まれ、かつ、前記再生速度に応じたフレーム間隔よりも、前記送信装置に保持され画面内符号化された第１のフレームから前記第１のフレームの次に画面内符号化された第２のフレームまでのフレーム間隔が長い場合に、前記受信手段が前記第２のフレームを重複して受信しないことを特徴とする請求項１記載の通信方法。