JP2009290691A - 送信装置、送信方法および受信装置 - Google Patents

Abstract

【課題】ストリーミング配信において、ネットワークの状況に応じて伝送する画像の解像度を変更し、さらに、受信した画像をアップスケールすることにより高品位な画像を再生する。
【解決手段】１．ネットワーク環境が悪く、受信端末の負荷が高い場合：ａ−１（ＳＤ画像を送信し、受信端末がＳＤ画質で再生）２．ネットワーク環境が悪く、受信端末の負荷が低い場合：ａ−２（ＳＤ画像を送信し、受信端末がＳＤ画質をＨＤ画質へアップスケール）３．ネットワーク環境が良く、受信端末の負荷が高い場合：ＳＤ画像を送信した時にアップスケールを行わない。ＨＤ画質のままで再生する処理が望ましい。４．ネットワーク環境が良く、受信端末の負荷が低い場合：受信端末の処理は、３通りの処理の何れも行うことができる。好ましくは、ＨＤ画像を送信し、ＨＤ画質で再生する。
【選択図】図５

Description

この発明は、例えばＩＰ通信網を介して送信装置および受信端末が接続された通信システムにおける送信装置、送信方法および受信装置に関する。

近年、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。例えば映像ファイルや音声ファイルでは、ダウンロード型伝送方式の場合、配信サーバからデータファイルを一旦受信側端末にダウンロードして、その後ファイルが再生される。したがって、この方式では、ファイルの転送が完全に終わるまでは、当該ファイルを再生できず、長時間再生やリアルタイム再生などには不向きである。ストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、受信したデータを再生できるため、インターネット電話、遠隔テレビ会議、ビデオオンデマンドといったインターネットサービスに利用されている。

このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC（Internet Engineering Task Force Request For Comments）1889で規定されているRTP(Realtime Transport Protocol)がある。RTP によるデータ転送では、時間情報としてパケットにタイムスタンプが付加される。タイムスタンプによって送信側と受信側の時間的関係が把握され、その結果、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとって再生することができる。

ここで、RTP は、実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはRTP が提供するトランスポートサービスの範疇ではないため、RTP パケットは、他のパケットと同様に配送遅延やパケット損失がおきる可能性がある。特に、有線区間で１０^-5以上のエラーがあり、無線区間で１０^-3以上のエラーがある状況の下では、配信するメディアの品質を保持する観点から、RTP をそのまま利用することは、信頼性の低下を招く。

このような点から、RTP パケットのシーケンス番号を利用して損失したパケットを検知し、ARQ(Auto Repeat reQuest)によって送信側に再送要求を送信し、送信側が損失したパケットを再送する方法が考えられる。また、信頼性が高いTCP(Transmission Control Protocol)で再送要求および再送パケット送信を行わせる方法がある。しかし、TCP は、エラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性もある。

また、エラー訂正としてFEC(Forward Error Correction) という方法が知られている。この方法は、誤り訂正を行うためのFEC データを冗長に送信して、エラーが発生した場合にはこのFEC データをもとに修復するものである。上述したARQ に比べると再送にかかる遅延がない分、遅延時間を低く抑えられる。しかしながら、冗長データを付加するためにパケット損失が非常に少ない伝送路においてはスループットは低下する。さらに、FEC は、端末側での誤り検出と符号処理が複雑なため受信端末側の処理能力に依存してしまう。このように、ネットワーク状況と受信端末に合わせて最適な付加FEC データを一意に決定することが難しく、処理時間のオーバーヘッドの問題が常につきまとう。

上述した方法は、パケットロス対策、エラー対策の手法の一例である。さらに、パケットロスの原因となるネットワークの輻輳そのものを起こさないようにする方法が知られている。よりさらに、エラー対策なしに転送する方法として、伝送レート制御を行う方法や、動画像のフレームレート制御といった方法が存在する。すなわち、送信端末側で動画像を転送する際に、ネットワークの状況が悪化した場合、通常の転送レートよりも低いレートで動画像やデータを送信することで、パケットロスや遅延が起こる確率を低くする方法である。ストリーミングシステムにおいては、これらのエラー対策やレート制御を単独または組み合わせて利用される。

例えば下記の特許文献１には、通信網の伝送状態が取得され、伝送状態を基に、送信パケットの伝送レートを増加、減少または維持させる制御を行うと共に、再送要求があった時に、再送パケットの再送を制御することが記載されている。

特開２００５−１３６５４８号公報

特許文献１に記載されているようなレート制御は送信側（サーバ）の制御だけで行える利点がある。しかしながら、動画像などのマルチメディアデータの伝送において、伝送レートを下げることは、再生品質の劣化を生じさせることとなる。動画像の品質向上のためのアルゴリズムは多数存在する。しかしながら、リアルタイムに解像度や画質を向上する方法は少なく、これらは主にディスクメディアのような蓄積型メディアを対象とし、転送されるネットワークの環境や再生される受信端末の演算能力によって動的に変化させるものは無かった。

したがって、この発明の目的は、ネットワークの状況の良否に加えて受信端末のアップスケールを行う処理装置の負荷の程度に応じて送信する画像データの解像度を制御する送信方法および受信装置サーバ装置およびリモートコントロール方法を提供することにある。

上述した課題を解決するために、この発明は、送信する画像データとして、第１の画像データと第１の画像データに比して解像度の高い第２の画像データを保持するバッファメモリと、
第１および第２の画像データの一方をストリーミングデータとして送信する送信部と、
受信端末からネットワークの状況および受信端末内のアップスケールを行うための処理装置の負荷の程度を表す制御メッセージを受信する通信部と、
制御メッセージからネットワークの状況が悪い場合には、第１の画像データを送信し、ネットワークの状況が良い場合には、第１および第２の画像データの一方を送信し、ネットワークの状況が良く且つ処理装置の負荷が高い場合には、受信端末においてアップスケールを行わないように制御する制御部と
を有する送信装置である。

好ましくは、制御部は、ネットワークの状況が良く且つ処理装置の負荷が低い場合には、受信端末において、受信した画像データの解像度を変更しない処理方法とアップスケールを行う処理方法との一方を行うように、受信端末を制御する。

好ましくは、制御メッセージに対する返答の中に、受信端末の処理方法を指示する情報を含ませる。

好ましくは、アップスケールのアルゴリズムを複数用意され、アルゴリズムによって処理装置の負荷が変化する。

この発明は、送信する画像データとして、第１の画像データと第１の画像データに比して解像度の高い第２の画像データを保持し、第１および第２の画像データの一方をストリーミングデータとして送信する送信ステップと、
受信端末からネットワークの状況および受信端末内のアップスケールを行うための処理装置の負荷の程度を表す制御メッセージを受信する通信ステップと、
制御メッセージからネットワークの状況が悪い場合には、第１の画像データを送信し、ネットワークの状況が良い場合には、第１および第２の画像データの一方を送信し、ネットワークの状況が良く且つ処理装置の負荷が高い場合には、受信端末においてアップスケールを行わないように制御する制御ステップと
を有する送信方法である。

この発明は、第１の画像データと第１の画像データに比して解像度の高い第２の画像データの一方をストリーミングデータとして受信し、受信したデータを保持するバッファメモリと、
第１の画像データを第２の画像データへのアップスケールを行うための処理装置の負荷の程度をモニタするモニタと、
第１の画像データを受信した場合に、処理装置の負荷が高い場合には、アップスケールを行わないように制御する制御部と
を有する受信装置である。

この発明によれば、上述した従来の技術における問題点、すなわち、リアルタイム配信やストリーミング配信において、ネットワークの状況に応じて伝送する画像の解像度を落としビットレートを低くすることにより、転送を円滑に行い、また、受信した動画像をアップスケールすることにより高品位な画像を再生することができる。
この発明は、再生装置のアップスケールのための処理装置の負荷に応じて再生可能な動画像の解像度を推測することで、安定かつ再生装置における最大限の品質での再生およびサービスを提供が可能となる。
この発明は、受信側でネットワークの状態を測定し、その結果を元に解像度を推測して送信端末に通知することによって、Qos(Quality Of Service: サービス品質）が保証されないネットワークに柔軟に対応できる。

以下、この発明の実施の形態について図面を参照しながら説明する。なお、以下に説明する実施の形態は、この発明の好適な具体例であり、技術的に好ましい種々の限定が付されているが、この発明の範囲は、以下の説明において、特にこの発明を限定する旨の記載がない限り、実施の形態に限定されないものとする。

この発明の一実施の形態は、ストリーム型の伝送方式を採用している。この方式では、受信装置が、送信装置から送信されてくるデータを受信すると共に、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般に、ストリーミングデータと称する。より具体的には、画像データにＭＰＥＧ（Moving Picture Experts Group）符号化処理を適用することにより生成されるＭＰＥＧストリームがＩＰ（Internet Protocol ）パケットに格納される。ＩＰパケットがインターネットを介して伝送される。

この発明の一実施の形態は、図１に示すシステム構成を有する。すなわち、送信装置１００に対して通信網例えばＩＰ網３００を介して複数の受信端末２００が接続されている。ＩＰ網３００は、ＩＰを利用したネットワーク（インターネット、有線ＬＡＮ(Local Area Network)、無線ＬＡＮ等）のことである。送信装置１００がサーバとしての機能を有し、受信端末２００がクライアントとしての機能を有する。受信端末２００は、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistance ）、携帯電話機等である。かかる通信システムは、送信装置１００と受信端末２００との間で、データをパケット単位で通信し、受信端末２００では、受信したパケットの順次再生（ストリーミング再生）がなされる。

送信装置１００は、レコーダ一体型ビデオカメラ１０１およびマイクロホン１０２によりそれぞれ取得した映像データおよびオーディオデータ（以下、これらのコンテンツデータを総称してメディアデータと適宜称する。但し、圧縮符号化されている映像データ、オーディオデータも特に区別が必要な場合を除いてメディアデータと称する。）がインターフェース１０３を介してバス１０４に入力される。メディアデータがストリーミングデータとしてＩＰ網３００を通じて受信端末２００に対して送信される。ストリーミングデータは、ストリーミング再生に供されるデータであり、時間の経過に対応して順次送信または受信が要求されるデータである。

バス１０４に対して、ＣＰＵ(Central Processing Unit）１０５、ＲＯＭ(Read Only Memory ）１０６、ＲＡＭ(Random Access Memory ）１０７、外部記憶装置１０８が接続される。ＣＰＵ１０５は、ＲＯＭ１０６または外部記憶装置１０８に記録されているプログラムに従って各種の処理を実行する。ＲＡＭ１０７には、ＣＰＵ１０５が実行するプログラムやデータ等が記憶される。

さらに、送信装置１００において、バス１０４に対して、キーボード、マウス、スイッチ等からなる入力装置１０９、モニタとしての表示装置１１０および通信インターフェース１１１が接続される。ＣＰＵ１０５は、入力装置１０９から入力される指令に対応して各種の処理を実行する。外部記憶装置１０８は、例えばハードディスクによって構成され、ＣＰＵ１０５が実行するプログラムや各種のデータを記録する。例えば送信するメディアデータが予め外部記憶装置１０８に蓄積される。通信インターフェース１１１は、ＩＰ網３００を通じて受信端末２００と通信する。

受信端末２００は、送信装置１００と同様に、バス２０４に対して、ＣＰＵ２０５、ＲＯＭ２０６、ＲＡＭ２０７、外部記憶装置２０８、入力装置２０９、モニタとしての表示装置２１０、通信インターフェース２１１を備えている。通信インターフェース２１１を通じて送信装置１００とＩＰ網３００を通じて通信を行う。さらに、メディアデータ例えばオーディオデータを再生する再生装置２１２と、映像信号を再生する表示装置２１３を備えている。

図１に示すシステムにおいて、送信装置１００がカメラ１０１およびマイクロホン１０２によって取得されたメディアデータをインターフェース１０３を介してＲＡＭ１０７に取り込む。メディアデータは、予め蓄積されている場合もある。ＣＰＵ１０５の処理によって、メディアデータがストリーミングデータに変換され、ストリーミングデータが通信インターフェース１１１を通じておよびＩＰ網３００に伝送される。この場合、後述するように、ネットワーク環境の良否と受信端末２００の処理の負荷の程度に応じて送信されるメディアデータ（画像データ）の解像度が制御される。例えば高解像度（ＨＤと適宜略す）画像データと標準解像度（ＳＤと適宜略す）画像データとの一方が送信される。

ＳＤ画像は、（水平画素数×垂直画素数）が例えば（６４０×４８０）の画像（ＶＧＡ（Video Graphics Array））である。ＨＤ画像は、１０８０ｉ、７２０ｐ、１０８０ｐ等の画像である。ＨＤ画像の表記は、（走査線数、ｐ（プログレッシブ）またはｉ（インタ−レス））である。例えば１０８０ｐは、走査方式がプログレッシブで、（水平画素数×垂直画素数）が（１９２０×１０８０）の画像を表す。ＨＤ画像の種類としては、上述したフォーマット以外のもの（ＸＧＡ（eXtended Graphics Array,１０２４×７６８画素）等のフォーマットも存在する。この発明においては、何れのフォーマットのＨＤ画像を使用しても良い。

送信装置１００から送信されたストリーミングデータを受信端末２００が通信インターフェース２１１を通じて受信し、受信したストリーミングデータがバッファメモリとしてのＲＡＭ２０７に蓄積される。ＣＰＵ２０５の処理によって、再生処理がなされ、表示装置２１３によって画像が表示され、再生装置２１２によって音声が再生される。

受信端末２００は、受信したメディアデータがＳＤ画像データの場合、ＳＤ画像データとして再生する処理以外に、ＳＤ画像をＨＤ画像に変換するアップスケールを行うことが可能とされている。上述したように、ＨＤ画像のフォーマットは、複数存在する。受信端末２００において、何れか一つのフォーマットのＨＤ画像にアップスケールすることが可能とされたり、他のＨＤ画像の形式例えばアスペクト比を（４：３）に維持したままアップスケールすることが可能とされている。アップスケールの方法は、既に「ＰＬＡＹＳＴＡＴＩＯＮ３」（ソニー株式会社の登録商標）等で実用化されている複数のＣＰＵを使用した画像処理方法を採用できる。

図２は、この発明の一実施の形態のシステム構成の機能的なブロック図である。送信装置１００では、レコーダ一体型ビデオカメラ１０１およびマイクロホン１０２によって取得されたメディアデータがエンコーダ１１によって圧縮符号化される。エンコーダ１１は、図１におけるＣＰＵ１０５、ＲＯＭ１０６およびＲＡＭ１０７によるソフトウェア処理で実現される。映像データは、ＭＰＥＧ２(Moving Picture Experts Group Phase 2)、ＡＶＣ(Advanced Video Coding) （Ｈ．２６４）、ＭＰＥＧ４等で圧縮され、オーディオデータは、ＡＡＣ(Advanced Audio Coding) 、ＭＰＥＧオーディオ等で圧縮される。

ビデオカメラ１０１およびマイクロホン１０２は、リアルタイムに取得されたメディアデータを送信装置１００のエンコーダ１１に対して供給する。エンコーダ１１からの符号化データがバッファメモリ１２（図１中のＲＡＭ１０７が対応）に蓄積される。リアルタイムデータに限らず、ハードディスク、ディスク記録再生部等の蓄積部１３（図１中の外部記憶装置１０８が対応）に蓄積されている圧縮メディアデータの送信が行われる場合もある。蓄積部１３の再生データがバッファメモリ１２に供給される。

バッファメモリ１２に蓄積されているメディアデータが送信部１４（図１中の通信インターフェース１１１が対応）に供給され、パケットが連続するストリーミングデータが送信部１４により生成される。ストリーミングデータが送信部１４からＩＰ網３００に送信される。送信部１４は、リアルタイムに取得されたメディアデータまたは蓄積部１３に蓄積されているメディアデータをストリーミングデータとして送信する機構を有する。一般的には、受信端末の要求に応じて送信を開始するが、いわゆるマルチキャストと呼ばれる多数の受信端末向けの送信を送信側主導で行うようにしても良い。

さらに、送信装置１００は、受信部１５（図１中の通信インターフェース１１１が対応）を有する。ＩＰ網３００を通じて受信端末２００からネットワーク環境の良否の情報と、受信端末２００のアップスケール処理部を構成するＣＰＵの負荷の程度を示す情報（制御メッセージと称する）とが受信部１５によって受信される。受信部１５において受信された制御メッセージが制御部１６（図１中のＣＰＵ１０５が対応）に供給される。制御部１６は、制御メッセージに応じて、後述するように、エンコーダ１１および蓄積部１３を制御することによって、送信されるストリーミングデータにおける動画像の解像度を変更する。

例えばエンコーダ１１の圧縮率が制御部１６によって制御され、ＳＤ画像とＨＤ画像の一方がエンコーダ１１から出力される。蓄積部１３には、ＨＤ画像が蓄積されており、ＳＤ画像の出力を制御部１６が指示すると、ＨＤ画像をダウンスケールしたＳＤ画像を蓄積部１３が出力する。さらに、蓄積部１３には、当初からＳＤ画質のコンテンツが蓄積される場合もある。

受信端末２００の受信部２１（図１中の通信インターフェース２１１が対応）がＩＰ網３００を通じて送信装置１００からのストリーミングデータを受信する。受信部２１によってストリーミングデータがメディアデータに変換される。メディアデータがパケット解析部２２（図１中のＣＰＵ２０５およびＲＡＭ２０７が対応）に供給され、パケットの損失の程度等が解析される。バッファメモリ２３（図１中のＲＡＭ２０７が対応）に受信メディアデータが蓄積される。

バッファメモリ２３からのメディアデータがデコーダ２４に供給され、メディアデータが伸張処理を受ける。デコーダ２４は、図１におけるＣＰＵ２０５、ＲＯＭ２０６およびＲＡＭ２０７によるソフトウェア処理で実現される。デコーダ２４からのメディアデータが受信端末２００に接続された表示装置２１３および再生装置２１２によって再生される。デコーダ２４に関連してアップスケールエンジン２７が備えられている。アップスケールエンジン２７は、ＣＰＵ、ＲＯＭおよびＲＡＭを使用してソフトウェア処理でアップスケールを行う。

アップスケールエンジン２７は、低い解像度の画像例えばＳＤ画像をより高い解像度の画像例えばＨＤ画像に変換するソフトウェア処理を行う。アップスケールを行うか否かは、受信端末２００におけるＣＰＵの負荷、ユーザの設定等に依存している。アップスケールエンジン２７を構成するＣＰＵの負荷を監視するＣＰＵモニタ２８が設けられている。ＣＰＵモニタ２８は、アップスケールエンジン２７を構成するＣＰＵの負荷の監視し、負荷の程度を表す情報を制御部２５に供給する。ＣＰＵモニタ２８は、ＣＰＵの演算負荷量を計測する。これは、ＣＰＵ演算負荷率を計測すれば良い。例えばアップスケールの方法が複数種類用意されている場合、アップスケールの方法によってＣＰＵの負荷が異なる。アップスケールエンジン２７が複数のＣＰＵによって構成されている場合には、使用されるＣＰＵの個数をＣＰＵの負荷として検出しても良い。

さらに、受信端末２００の受信部２１に関連してネットワークモニタ２６が設けられている。ネットワークモニタ２６は、パケットのロスやジッターなどをモニタリングすることで、ネットワーク環境の良否を計測する。データ受信に伴うパケットロス状況や遅延状況からネットワーク環境を把握し、ネットワーク環境の情報を制御部２５に供給する。制御部２５は、ネットワーク環境に応じてビットレートを変更する要求を制御メッセージとして送信部２９を介して送信装置１００に対して送信する。ネットワーク環境が悪い場合には、ビットレートが下げる処理（例えばＳＤ画像の送信）がなされ、ネットワーク環境が良い場合には、ビットレートを上げる処理（例えばＨＤ画像の送信）がなされる。

制御部２５は、ネットワークモニタ２６からのネットワーク環境の良否の情報と、アップスケールエンジン２７からのＣＰＵの負荷の程度とを受け取って、制御メッセージを生成する。生成した制御メッセージが送信部２９からＩＰ網３００を通じて送信装置１００の受信部１５に送信される。

制御メッセージを送信することによって、ネットワーク環境が悪いときには、正常に受信できると思われる低解像度のデータの送信を要求する。その結果、送信データ量を減らすことができ、データをロスなく受信端末に配信することができる。ここで、受信端末側での演算負荷が低い場合には、低解像度のＳＤ画像をアップスケールして、高解像度のＨＤ画像とすることができる。一方、演算負荷が高い場合には、アップスケールを行うのが困難と判断し、そのまま再生する。または、演算量が比較的少ないアルゴリズムのアップスケールを行う。なお、アップスケールを行うタイミングについては、受信端末が任意に設定できる。例えば、制御メッセージに対する返答ＡＣＫを受信したた時点などが考えられる。

受信端末２００から送信装置１００に送信される制御メッセージには、例えば以下のような情報が記述される。
１）ネットワーク状況に関して
・パケットロス率
・ジッター
・リンクスピード
２）ＣＰＵ演算負荷
・ＣＰＵ負荷率（％）
・アップスケールできるかどうかの判断

制御メッセージは、データ送受信中において、定期的に送られる。例えば、１０秒間隔おきにモニタリングした結果が送信される。なお、送信間隔は、任意の間隔を設定できる。さらに、最初のデータ送信時のみ、制御メッセージを送信しても良い。送信装置１００は、制御メッセージを正常に受信した場合には、受信応答（ＡＣＫ）を受信端末２００に送信する。

図３は、送信装置１００の動作の流れを示す。ステップＳ１において、送信開始の準備が完了する。ステップＳ２において、送信するメディアデータが取得される。ビデオカメラ１０１によりリアルタイムにデータが取得されるか、蓄積部１３から蓄積されているデータが取得される。

ステップＳ３において、エンコーダ１１によるエンコードが必要か否かが判定される。ここでのエンコードは、解像度をＨＤからＳＤに変換するための処理を意味している。後述するように、送信装置１００は、制御メッセージの内容にしたがって送信するメディアデータの解像度を設定する。エンコードが不要と判定されると、ステップＳ４に処理が移り、データ送信が準備される。エンコードが必要と判定されると、ステップＳ５において、エンコード（ＨＤからＳＤへの変換）が行われる。例えばビデオカメラ１０１からの撮像データの場合には、圧縮符号化のエンコードが必要と判定され、蓄積部１３からのデータの場合には、エンコードが不要と判定される。

データ送信準備（ステップＳ４）においては、メディアデータがバッファメモリ１２に蓄積され、メディアデータがパケットに格納される。そして、ステップＳ６において、パケットから構成されるストリーミングデータが送信される。

ステップＳ７において、制御メッセージを受信したか否かが判定される。制御メッセージを受信しない場合には、処理がステップＳ２（データ取得）に戻る。制御メッセージを受信した場合には、ステップＳ８において、受信した制御メッセージを制御部１６に供給し、返答ＡＣＫを送信する。そして、処理がステップＳ２（データ取得）に戻る。制御メッセージは、受信端末２００のアップスケールエンジンを構成するＣＰＵの負荷の高低の情報とネットワーク環境の良否の情報とを有する。

図４は、受信端末２００の動作の流れを示す。ステップＳ１１において、送信装置１００から送信開始通知を受信する。ステップＳ１２において、送信されてきたパケットを受信する。

ステップＳ１３において、圧縮符号化のデコードが必要か否かが判定される。デコードが不要と判定されると、処理がステップＳ１４に移る。ステップＳ１４では、アップスケールを行うか否かが判定される。ステップＳ１３において、デコードが必要と判定されると、ステップＳ１５において、デコード処理がなされる。

ステップＳ１４において、アップスケールが不要と判定されると、処理がステップＳ１６に移る。ステップＳ１６において、受信したメディアデータが再生される。ステップＳ１４において、アップスケールが必要と判定されると、ステップＳ１７において、アップスケールが行われる。すなわち、ＳＤ画像がＨＤ画像に変換される。アップスケールにより得られたＨＤ画像がステップＳ１６において再生される。

ＳＤ画像を受信した場合にアップスケールを行うか否かは、送信装置１００からの指示または受信端末２００がＣＰＵの負荷に基づいて判定される。例えばＣＰＵの負荷が高い場合には、アップスケールが必要であってもアップスケールを行うことができない。この場合もアップスケール不要と判定される。さらに、ユーザの設定によってアップスケールを行わない場合もアップスケール不要と判定される。

受信端末２００では、ステップＳ２１においてパケットを受信すると、ネットワークモニタ２６によってネットワーク環境の状況の情報がステップＳ２２において取得されると共に、ＣＰＵモニタ２８によってアップスケールエンジン２７のＣＰＵの負荷の情報がステップＳ２５において取得される。そして、ステップＳ２３において、これらのネットワーク環境の状況の情報とＣＰＵの負荷の情報とを含む制御メッセージが作成される。ステップＳ２４において、制御メッセージが送信部２９から送信装置１００に対して送信される。

さらに、この発明の一実施の形態について説明する。送信装置１００の制御部１６は、受信端末２００から送信された制御メッセージに基づいて送信する動画像の解像度を変更する。また、受信端末２００においては、受信された動画像の解像度を取得し、ＣＰＵモニタ２８が検出したＣＰＵの負荷状況に応じてアップスケールを行う。場合によっては、アップスケールは行わない。また、アップスケールもアルゴリズムによって、演算処理負荷が異なるため、アルゴリズムも変更する。

これらの制御の一例を図５の制御テーブルに示す。ここでは、解像度をＳＤとＨＤの２段階に分けたが、より細かく分けても良い。ネットワーク状況に関しても、より細かくわけても良い。

さらに、送信装置１００によって受信端末２００の処理を指示しなくても良い。すなわち、送信側が解像度を変えなくても、ネットワーク環境の状況によって動的に受信端末側の判断でアップスケールの有無を実行しても構わない。

図５の例では、図５Ａに示すように、受信端末２００からの制御メッセージに含まれるネットワーク環境の良否と、受信端末のＣＰＵの負荷の高低とに応じた処理がなされる。図５Ａの表中の「ａ」の表記は、図５Ｂに示すように、送信データの画像解像度がＳＤであることを示し、「ｂ」の表記は、送信データの画像解像度がＨＤであることを示す。さらに、図５Ａの表中の「１」の表記は、図５Ｃに示すように、受信端末の処理がＳＤ画質で再生することを示す。「２」の表記は、受信端末の処理がＳＤ画質をＨＤ画質にアップスケールすることを示す。「３」の表記は、図５Ｃに示すように、受信端末の処理がＨＤ画質のままで再生することを示す。

図５Ａに示す表の各処理につてい説明する。
ネットワーク環境が悪く、受信端末の負荷が高い場合：ａ−１（ＳＤ画像を送信し、受信端末がＳＤ画質で再生）
ネットワーク環境が悪く、受信端末の負荷が低い場合：ａ−２（ＳＤ画像を送信し、受信端末がＳＤ画質をＨＤ画質へアップスケール）
ネットワーク環境が良く、受信端末の負荷が高い場合：ＳＤ画像を送信した時にアップスケールを行わない。ＨＤ画像を送信し、受信端末がＨＤ画質のままで再生する処理が望ましい。但し、メディアデータがＳＤ画質であったり、ネットワークがＨＤ画像の伝送に適していない場合には、ＳＤ画像を送信し、受信端末がＳＤ画像を再生する場合もある。）
ネットワーク環境が良く、受信端末の負荷が低い場合：受信端末の処理は、３通りの処理の何れも行うことができる。好ましくは、ＨＤ画像を送信し、ＨＤ画像を再生する。但し、ネットワークの制約、メディアデータがＳＤ画質である場合には、ＳＤ画像をＨＤ画像にアップスケールする。さらに、ユーザがＳＤ画質を設定している場合には、ＳＤ画像が送信される。

上述した送信装置１００および受信端末２００における制御の一例を説明する。まず前提として、ＨＤ解像度のデータを送受信しているときに、ネットワーク環境が悪化したと想定する。この場合、下記のような順序で制御がなされる。

１）送信装置１００がＨＤ解像度のデータを送信する。
２）受信端末２００がＨＤ解像度のデータをデコードして再生する。
３）受信端末２００がネットワークの状況が悪化したことを検知し、制御メッセージを送信する。このときに、例えば、「パケットロス率５％、ＣＰＵ負荷率３０％」という情報を表す制御メッセージが送信される。
４）送信装置１００が制御メッセージを受け取り、送信データをＨＤ解像度からＳＤ解像度へ変更する。
５）送信装置１００が解像度を変更したことを、制御メッセージに対する返答ＡＣＫに含めて送信する。
６）制御メッセージの返答ＡＣＫを受け取った受信端末２００は、ＣＰＵ負荷率３０％の場合にはアップスケールできると判断し、ＳＤ解像度のデータをアップスケールし、アップスケールしたデータを再生する。
７）上述した動作を繰り返している最中に、ネットワーク状況が良くなった場合には、元のＨＤ解像度で送信装置１００がデータを送信することになる。

この発明は、上述の実施の形態に限定されるものではなく、この発明の技術的思想に基づく各種の変形が可能である。例えば送信装置は、他のサーバ等から受け取ったストリーミングデータを中継して受信端末に対して送信するようにしても良い。さらに、受信端末が受信した低解像度の画像データをアップスケールして他の受信端末に送信するようにしても良い。さらに、この発明は、低ビットレートにおける動画像配信サービスにおいて、アップスケールの有無およびアルゴリズムの選択により品質向上度を差別化できるので、料金に応じてサービスを差別化するビジネスモデルを構築することができる。

この発明に係る通信システムの一実施の形態を示すブロック図である。 この発明に係る通信システムの一実施の形態を機能ブロックと表したブロック図である。 送信装置の動作の流れを示すフローチャートである。 受信端末の動作の流れを示すフローチャートである。 送信装置の制御例を示す略線図である。

符号の説明

１１・・・エンコーダ
１３・・・蓄積部
１４・・・送信部
１５・・・受信部
１６・・・制御部
２１・・・受信部
２４・・・デコーダ
２５・・・制御部
２６・・・ネットワークモニタ
２７・・・アップスケールエンジン
２８・・・ＣＰＵモニタ
２９・・・送信部
１００・・・送信装置
２００・・・受信端末
３００・・・ＩＰ網

Claims (6)

1. 送信する画像データとして、第１の画像データと上記第１の画像データに比して解像度の高い第２の画像データを保持するバッファメモリと、
   上記第１および第２の画像データの一方をストリーミングデータとして送信する送信部と、
   受信端末からネットワークの状況および上記受信端末内のアップスケールを行うための処理装置の負荷の程度を表す制御メッセージを受信する通信部と、
   上記制御メッセージから上記ネットワークの状況が悪い場合には、上記第１の画像データを送信し、上記ネットワークの状況が良い場合には、上記第１および第２の画像データの一方を送信し、上記ネットワークの状況が良く且つ上記処理装置の負荷が高い場合には、上記受信端末においてアップスケールを行わないように制御する制御部と
   を有する送信装置。
2. 上記制御部は、上記ネットワークの状況が良く且つ上記処理装置の負荷が低い場合には、上記受信端末において、受信した画像データの解像度を変更しない処理方法とアップスケールを行う処理方法との一方を行うように、上記受信端末を制御する請求項１記載の送信装置。
3. 上記制御メッセージに対する返答の中に、上記受信端末の処理方法を指示する情報を含ませる請求項１記載の送信装置。
4. 上記アップスケールのアルゴリズムを複数用意され、上記アルゴリズムによって上記処理装置の負荷が変化する請求項１記載の送信装置。
5. 送信する画像データとして、第１の画像データと上記第１の画像データに比して解像度の高い第２の画像データを保持し、上記第１および第２の画像データの一方をストリーミングデータとして送信する送信ステップと、
   受信端末からネットワークの状況および上記受信端末内のアップスケールを行うための処理装置の負荷の程度を表す制御メッセージを受信する通信ステップと、
   上記制御メッセージから上記ネットワークの状況が悪い場合には、上記第１の画像データを送信し、上記ネットワークの状況が良い場合には、上記第１および第２の画像データの一方を送信し、上記ネットワークの状況が良く且つ上記処理装置の負荷が高い場合には、上記受信端末においてアップスケールを行わないように制御する制御ステップと
   を有する送信方法。
6. 第１の画像データと上記第１の画像データに比して解像度の高い第２の画像データの一方をストリーミングデータとして受信し、受信したデータを保持するバッファメモリと、
   上記第１の画像データを上記第２の画像データへのアップスケールを行うための処理装置の負荷の程度をモニタするモニタと、
   上記第１の画像データを受信した場合に、上記処理装置の負荷が高い場合には、アップスケールを行わないように制御する制御部と
   を有する受信装置。

Images