JP2004192140A - Data communication system, data transmitting device, data receiving device and method, and computer program - Google Patents

Data communication system, data transmitting device, data receiving device and method, and computer program Download PDF

Info

Publication number
JP2004192140A
JP2004192140A JP2002356980A JP2002356980A JP2004192140A JP 2004192140 A JP2004192140 A JP 2004192140A JP 2002356980 A JP2002356980 A JP 2002356980A JP 2002356980 A JP2002356980 A JP 2002356980A JP 2004192140 A JP2004192140 A JP 2004192140A
Authority
JP
Japan
Prior art keywords
data
server
client
request
encoded data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002356980A
Other languages
Japanese (ja)
Other versions
JP2004192140A5 (en
Inventor
Yasushi Mizuno
泰志 水野
Satoshi Futenma
智 普天間
Kenji Yamane
健治 山根
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2002356980A priority Critical patent/JP2004192140A/en
Publication of JP2004192140A publication Critical patent/JP2004192140A/en
Publication of JP2004192140A5 publication Critical patent/JP2004192140A5/ja
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To provide a device and method capable of realizing an optimum data transmission according to a client request. <P>SOLUTION: In the transmitting processing of hierarchically encoded data, a server transmits a message storing server retaining data mode identification information to a client, and the client receives the server data mode identification information and transmits information showing a hierarchically encoded data mode according to the processing capability of the client to the server. The server extracts or generates encoded data conformable to the client, and transmits them to the client. The server thus can transmit various structures of data by data extraction according to the client's request. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、データ受信側の希望するデータ処理態様に応じた最適な符号化データを効率的に伝送することを可能としたデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
現在、インターネット通信など、様々な通信媒体を介して様々なデータ転送が行なわれている。昨今では、画像データ、特に動画像データのネットワークを介した転送が盛んに行なわれている。画像データ、特に動画データは、送信側で符号化（圧縮）処理によりデータ量を減少させてネットワーク上に送出し、受信側で符号化された受信信号を復号（伸長）処理した後、再生する処理が一般的に行なわれている。
【０００３】
画像圧縮処理の最も知られた手法にＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ）圧縮技術がある。近年、ＭＰＥＧ圧縮により生成されるＭＰＥＧストリームをＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）に従ったＩＰパケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム、あるいはこのようなシステムにおける画像データ転送方法に関する技術開発が盛んに行なわれている。
【０００４】
ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信においては、異なる能力を持つ端末を受信端末として、データ送受信が行われることを想定する必要がある。例えば、１つの情報送信ソースからの送信データは、携帯電話などのような解像度の低いディスプレイと処理能力の低いＣＰＵを有する受信端末によって受信されディスプレイに表示する処理が実行され、かつ、デスクトップパソコンのように高解像度のモニターと高い処理能力のＣＰＵを有する受信端末によって受信されて表示処理が実行される。このように、処理能力の異なる様々な受信端末を相手としたデータ送信が行なわれる。このように様々な受信端末において処理能力等に応じた受信処理、表示処理を実行させる１つの手法として、送受信するデータの符号化を階層化させて実行する方法、すなわち、階層符号化を利用した通信システムが考えられている。
【０００５】
階層符号化によるデータ配信は、例えば、高解像度のディスプレイを有する受信端末においてのみ処理する符号化データと、高解像度のディスプレイを有する受信端末および低解像度のディスプレイを有する受信端末の双方において共通に処理する符号化データとを、それぞれ区別可能な態様でパケット化して配信し、受信側において、データを選別して処理可能としたものである。
【０００６】
階層符号化が可能な圧縮・伸張方式としては、例えばＭＰＥＧ４とＪＰＥＧ２０００によるビデオストリームをあげることができる。ＭＰＥＧ４ではＦｉｎｅＧｒａｎｕａｒｉｔｙ Ｓｃａｌａｂｉｌｉｔｙ技術を規格に取り込みプロファイル化する予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。また、ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００は、ウェーブレット（Ｗａｖｅｌｅｔ）変換の特徴を生かし、空間解像度をベースにパケット化することや、あるいは画質をベースに階層的にパケット化することが可能である。またＪＰＥＧ２０００は静止画だけでなく動画を扱えるＭｏｔｉｏｎ ＪＰＥＧ２０００（Ｐａｒｔ ３）規格により、階層化したデータをファイルフォーマットで保存することが可能である。
【０００７】
さらに、階層符号化を適用したデータ配信の具体案として提案されているものとして、ＤＣＴ（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ）ベースの技術を用いたものがある。これは配信情報となる例えば画像データをＤＣＴ処理し、ＤＣＴ処理により高域と低域とを区別した階層化を実現し、高域と低域との階層で区分したパケットを生成してデータ配信を実行する方法である。
【０００８】
このような階層符号化された画像データを配信する場合、リアルタイム性が要求されることが多く、そのためインターネット上での通信プロトコルとしてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が用いられる。さらに、ＵＤＰの上のレイヤにおいてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用い、通信パケットに格納されるデータフォーマットは、各アプリケーション毎、すなわち符号化方式毎に定義されたフォーマットに従うことになる。
【０００９】
インターネット等のネットワーク環境を利用して、サーバから様々なクライアントへデータを送信する場合、利用可能なネットワーク帯域や、クライント側のデータ処理能力、すなわち復号（デコード）処理あるいはディスプレイ表示能力等が異なる場合がある。すなわち、各クライアントが望む送信データのビットレートが異なることになる。従って、データ送信側のサーバは予め複数のビットレートでデータをエンコードし、複数のビットレートデータを保存し、クライアントの要求に応じて保存データから選択したデータを送信するといった処理が行われていた。
【００１０】
例えば、利用可能なネットワーク帯域が広ければ、クライアントは高いビットレートのデータを要求すると考えられるため、サーバは予め保存しておいた複数のデータの中から高いビットレートのデータを送信する。逆に利用可能帯域が狭ければ、クライアントは低ビットレートのデータを要求し、それに応じてサーバはデータを送信することになる。
【００１１】
このような、クライアント毎の送信データ適性を考慮した画像データ伝送処理構成を開示した従来技術として例えば特許文献１がある。特許文献１には、画像送信装置側において、データの伝送状況を検出し、伝送状況に応じて画像データの圧縮処理態様を変更する構成が開示されている。データ送信装置は、データ送信先に応じた伝送状況情報を有し、伝送状況が悪い地域に対するデータ伝送の場合には、例えば解像度を落としてデータ量を削減した圧縮処理を施したデータを送信する。一方、伝送状況が良好な地域に対するデータ伝送の場合には、解像度を向上させ、データ量の多い圧縮処理を施したデータを送信する。この構成により、状況に応じたデータ伝送を可能とした構成が開示されている。
【００１２】
しかし、この特許文献１に開示の構成は、データ送信装置側において、データ伝送状況に応じて圧縮処理態様を動的に変更して処理を行なうことが必要となり、データ受信装置側のデータ要求が多発すると、その要求毎に圧縮処理態様を変更して実行することが必要となり、データ送信側の処理負荷が過大になるという問題がある。
【００１３】
【特許文献１】
特開平１４−２６２２８８号公報
【００１４】
【発明が解決しようとする課題】
本発明は、上記問題点に鑑みてなされたものであり、様々なデータ受信側の状況に応じた最適な符号化データを伝送するとともにデータ送信側の処理負荷を軽減し、効率的な最適符号化データの伝送処理を可能としたデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１５】
【課題を解決するための手段】
本発明の第１の側面は、
階層符号化データの送信処理を実行するサーバと、前記サーバから階層符号化データを受信するクライアントからなるサーバクライアントシステムであり、
前記クライアントは、
前記サーバに対して送信するデータ要求メッセージに、クライアントの要求する階層符号化データ態様を示す要求データ態様識別情報を格納して送信する処理を実行する構成を有し、
前記サーバは、
前記クライアントから受信するデータ要求メッセージに含まれる前記要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成し、前記クライアントに対して送信する処理を実行する構成を有することを特徴とするサーバクライアントシステムにある。
【００１６】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記クライアントは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であり、前記サーバは、前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行する構成であることを特徴とする。
【００１７】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする。
【００１８】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、１フレームあたりのＪＰＥＧ２０００符号化データパケット（ＪＰ２パケット）数であることを特徴とする。
【００１９】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする。
【００２０】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記要求データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする。
【００２１】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする。
【００２２】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする。
【００２３】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記クライアントは、前記データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行し、前記サーバは、前記クライアントから受信するデータ仕様要求の応答として、サーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信する処理を実行する構成であり、前記クライアントは、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、クライアントの要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報として前記データ要求メッセージに格納して前記サーバに送信する処理を実行する構成であることを特徴とする。
【００２４】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記クライアントは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったデスクライブ［ＤＥＳＣＲＩＢＥ］メソッドによりデータ仕様要求を前記サーバに送信し、前記サーバは、前記クライアントから受信する前記デスクライブ［ＤＥＳＣＲＩＢＥ］メソッドの応答として、サーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信し、前記クライアントは、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、クライアントの要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報としてＲＴＳＰに従ったプレイ［ＰＬＡＹ］メソッドの記述中に格納して前記サーバに送信する処理を実行する構成であることを特徴とする。
【００２５】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする。
【００２６】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする。
【００２７】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする。
【００２８】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする。
【００２９】
さらに、本発明のサーバクライアントシステムの一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする。
【００３０】
さらに、本発明の第２の側面は、
階層符号化データの送信処理を実行するサーバとしてのデータ送信装置であり、
クライアントとのデータ送受信を実行する通信部と、
前記通信部を介してクライアントから受信するデータ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御部と、
前記制御部の制御の下に抽出または生成した符号化データを格納した通信パケットを生成する通信パケット処理部とを有し、
前記通信パケット処理部において生成したクライアント対応の符号化データを格納した通信パケットをクライアントに対して送信する処理を実行する構成を有することを特徴とするデータ送信装置にある。
【００３１】
さらに、本発明のデータ送信装置の一実施態様において、前記クライアントは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であり、前記制御部は、前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行する構成であることを特徴とする。
【００３２】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置は、前記通信部を介してクライアントからデータ仕様要求を受信し、前記制御部は、記憶部に格納した階層符号化データの態様情報としてのサーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信する処理を実行する構成であることを特徴とする。
【００３３】
さらに、本発明のデータ送信装置の一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記サーバ保持データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする。
【００３４】
さらに、本発明のデータ送信装置の一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記サーバ保持データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする。
【００３５】
さらに、本発明のデータ送信装置の一実施態様において、前記サーバ保持データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする。
【００３６】
さらに、本発明のデータ送信装置の一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする。
【００３７】
さらに、本発明のデータ送信装置の一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする。
【００３８】
さらに、本発明の第３の側面は、
サーバから階層符号化データを受信するクライアントとしてのデータ受信装置であり、
前記データ受信装置は、
サーバとのデータ送受信を実行する通信部と、
自己の要求する階層符号化データ態様の決定処理を実行し、決定情報を前記通信部を介してサーバに送信するデータ要求メッセージに格納する要求データ態様識別情報として設定する制御部とを有し、
サーバに対する階層符号化データの要求メッセージ中に、前記要求データ態様識別情報を格納して送信する処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００３９】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であることを特徴とする。
【００４０】
さらに、本発明のデータ受信装置の一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする。
【００４１】
さらに、本発明のデータ受信装置の一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、１フレームあたりのＪＰＥＧ２０００符号化データパケット（ＪＰ２パケット）数であることを特徴とする。
【００４２】
さらに、本発明のデータ受信装置の一実施態様において、前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、前記要求データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする。
【００４３】
さらに、本発明のデータ受信装置の一実施態様において、前記要求データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする。
【００４４】
さらに、本発明のデータ受信装置の一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする。
【００４５】
さらに、本発明のデータ受信装置の一実施態様において、前記階層符号化データは、ＭＰＥＧフォーマットデータであり、前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする。
【００４６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、前記データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行するとともに、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、自己の要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報として前記データ要求メッセージに格納して前記サーバに送信する処理を実行する構成であることを特徴とする。
【００４７】
さらに、本発明の第４の側面は、
階層符号化データの送信処理を実行するデータ送信方法であり、
クライアントからデータ要求メッセージを受信するステップと、
前記データ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御ステップと、
抽出または生成した符号化データを格納した通信パケットを生成する通信パケット生成ステップと、
クライアント対応の符号化データを格納した通信パケットをクライアントに対して送信するステップと、
を有することを特徴とするデータ送信方法にある。
【００４８】
さらに、本発明のデータ送信方法の一実施態様において、前記制御ステップは、前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行するステップであることを特徴とする。
【００４９】
さらに、本発明のデータ送信方法の一実施態様において、前記データ送信方法は、さらに、前記通信部を介してクライアントからデータ仕様要求を受信するステップと、記憶部に格納した階層符号化データの態様情報としてのサーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信するステップと、を有することを特徴とする。
【００５０】
さらに、本発明の第５の側面は、
サーバに対する階層符号化データの要求処理を実行するデータ要求処理方法であり、
自己の要求する階層符号化データ態様の決定処理を実行する要求データ態様決定ステップと、
サーバに送信するデータ要求メッセージに前記決定ステップにおいて決定した要求データ態様を要求データ態様識別情報として格納するステップと、
前記データ要求メッセージをサーバに対して送信するステップと、
を有することを特徴とするデータ要求処理方法にある。
【００５１】
さらに、本発明のデータ要求処理方法の一実施態様において、前記データ要求メッセージは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドとしてサーバに対して送信することを特徴とする。
【００５２】
さらに、本発明の第６の側面は、
階層符号化データの送信処理を実行するデータ送信処理を実行するコンピュータ・プログラムであって、
クライアントからデータ要求メッセージを受信するステップと、
前記データ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御ステップと、
抽出または生成した符号化データを格納した通信パケットを生成する通信パケット生成ステップと、
クライアント対応の符号化データを格納した通信パケットをクライアントに対して送信するステップと、
を具備することを特徴とするコンピュータ・プログラムにある。
【００５３】
さらに、本発明の第７の側面は、
サーバに対する階層符号化データの要求処理を実行するデータ要求処理を実行するコンピュータ・プログラムであって、
自己の要求する階層符号化データ態様の決定処理を実行する要求データ態様決定ステップと、
サーバに送信するデータ要求メッセージに前記決定ステップにおいて決定した要求データ態様を要求データ態様識別情報として格納するステップと、
前記データ要求メッセージをサーバに対して送信するステップと、
を具備することを特徴とするコンピュータ・プログラムにある。
【００５４】
【作用】
本発明の構成によれば、階層符号化データの送信処理を実行するサーバと、サーバから階層符号化データを受信するクライアントからなるサーバクライアントシステムにおいて、クライアントからサーバに対して送信するデータ要求メッセージに、クライアントの要求する階層符号化データ態様を示す要求データ態様識別情報を格納して送信し、サーバが要求データ態様識別情報に基づいて、クライアント対応の符号化データを抽出または生成してクライアントに送信する処理を実行する構成としたので、クライアントの処理能力等に応じた最適なデータの送信が可能になる。
【００５５】
また、本発明の構成によれば、サーバは、記憶部に格納する唯一の符号化データから、クライアントの要求に応じてデータ抽出により様々な構成のデータを送信データとすることが可能となるので、サーバは様々なタイプのデータを複数格納する必要がなく効率的な処理が可能となる。
【００５６】
さらに、本発明の構成によれば、クライアントは、データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行し、サーバが応答として、サーバ保持データ態様識別情報を格納した応答メッセージをクライアントに送信し、クライアントは、サーバ保持データ態様識別情報に基づいて、クライアントの要求する階層符号化データ態様を決定することが可能となり、サーバが確実に保有する範囲でのデータ要求が可能となる。
【００５７】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５８】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５９】
【発明の実施の形態】
［システム概要及びデータ送受信構成例］
まず、本発明のシステム概要及びデータ送受信構成例について説明する。図１に本発明の適用可能なデータ送受信システム構成例を示す。本発明では図１のようにデータ送信装置としてのサーバ１１とデータ受信装置としてのクライアント２１，２２，２３がネットワーク１２に接続され、ネットワーク１２を介してデータの送受信がされる環境を想定する。なお、図には３つのクライアントを示しているが、クライアントはネットワーク上に多数接続されているものとする。
【００６０】
サーバ１１は、あらかじめエンコードされたデータをＨＤＤのような記録媒体に保存しておく。このときのエンコード方式として階層符号化を用いた画像圧縮方式を用いるものとする。以下の説明においては、エンコード済みのデータを送受信する方法を具体例と示すが、サーバ１１がリアルタイムエンコーディングを実行する構成にも本発明は適用可能である。また、クライアント２１，２２，２３は、サーバで用いられたエンコード方式に対応したデコード処理環境、すなわちデコーダを有し、デコードデータの出力手段としてのディスプレイあるいはスピーカ等を有する。
【００６１】
なお、本実施例においては、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続ネットワークを想定している。画像あるいは音声データ等の配信ではリアルタイム性が要求されることが多く、多くの場合インターネット上での通信プロトコルとしてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が用いられる。さらに、ＵＤＰの上のレイヤにおいてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用いる。コンテンツデータの伝送プレーンとしてＲＴＰを用いる一方、制御情報伝送プレーンとしてはＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を用いる。
【００６２】
ＲＴＳＰでは、制御機能として複数のメソッドが規定されており、例えば、クライアントからサーバに対してコンテンツを要求するメソッドとして規定されたデスクライブ［ＤＥＳＣＲＩＢＥ］、メディア（コンテンツ）の送信開始メソッドとして規定された［ＰＬＡＹ］、メディアのためのリソース要求とＲＴＳＰセッション開始メソッドとして規定された［ＳＥＴＵＰ］、セッション終了メソッドとして規定された［ＴＥＡＲＤＯＷＮ］等、様々なメソッド（制御機能）が適用可能である。
【００６３】
データ送信サイトのサーバ１１は、ウェーブレット変換、あるいはＤＣＴ等をベースとした階層符号化処理によって生成した階層符号化データを保有し、クライアントからのデータ要求に応じて保有する階層符号化データからクライアントに最適なデータを抽出し、必要に応じて符号化列の再設定としての並び替えを実行し、抽出データを通信パケットのペイロードとして格納した通信パケットを生成してデータ要求クライアントに対して送信する。
【００６４】
ネットワーク１２は通信パケットに設定されたアドレス情報に基づいて送信先へ通信パケットを運ぶ。データ送信態様は様々であり、例えばダイアルアップサービスを提供するサービスプロバイダネットワークを経由してクライアント２１へ通信パケットが送信されたり、あるいはＡＤＳＬを使ったサービスプロバイダネットワークを経由してクライアント２２へパケットが配信される。あるいは無線ネットワークにより基地局１３を経由して移動クライアント２３に通信パケットが配信される。
【００６５】
以下、本発明を適用した符号化データの送受信処理について、ＪＰＥＧ２０００、ＭＰＥＧ等、各種データ圧縮フォーマットに従った複数の処理例を説明する。
【００６６】
［実施例１］
まず、実施例１として、階層符号化方式にＪＰＥＧ２０００を適用し、伝送制御方式としてＲＴＳＰを用いた例について説明する。
【００６７】
ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００のような階層符号化処理は、レイヤあるいは解像度を細かく設定した階層区分設定が可能であり、処理能力の異なる様々なデータ受信端末に応じた任意のビットレートに対応することが可能である。また、ＪＰＥＧ２０００を基礎とした動画の圧縮フォーマットであるＪＰＥＧ２０００ビデオストリームはフレーム間相関のないイントラフレームの連続として構成されるものであるため、ネットワーク上においてパケットロスが生じても、ロスパケットに基づく他のパケットに対するエラー伝播が発生しないという利点がある。従って、ウェーブレット変換を適用するとブロックノイズが生じないため視覚上の画質の低下が抑制される。
【００６８】
以下、説明する実施例は、ウェーブレット変換を適用した階層符号化処理によって生成した階層符号化データを送受信するシステムである。データを送信するデータ送信装置としてのサーバは、データを受信するデータ受信装置としてのクライアントの能力、例えばディスプレイ解像度やＣＰＵの処理能力（例えば処理可能なビットレート）に応じて、最適な符号化データを送信する。
【００６９】
本発明のシステムにおいて、符号化データを保持し、符号化データを格納した通信パケットを生成して送信する処理を実行するデータ送信装置としてのサーバの構成および処理について説明する。図２にサーバの構成例を説明するブロック図を示す。
【００７０】
図２に示す例では、サーバ１００は制御部１０１、エンコーダ（符号化部）１０２、記憶部１０３、通信パケット処理部１０４、データ送受信部（ネットワークＩ／Ｆ）１０５を有する。
【００７１】
データ送受信部１０５を介してデータ受信装置であるクライアントに対して符号化データを格納した通信パケットが送信される。送信対象となる符号化データは、基本的には、記憶部１０３に格納されたデータである。すなわち、あらかじめエンコーダ（符号化部）１０２によって所定の符号化処理が実行され、記憶部１０３に格納された符号化データから、制御部１０１の制御の下にクライアントの希望する符号化データ態様に応じたデータ抽出処理が実行され、抽出された符号化データをペイロードとした通信パケットが通信パケット処理部１０４において生成されて、データ送受信部１０５を介してデータ受信装置であるクライアントに対して送信される。なお、クライアントに対するデータ送信処理に際して、エンコーダ（符号化部）１０２によって符号化処理を実行し、符号化データを通信パケット処理部１０４において通信パケットに格納してクライアントに送信する構成としてもよい。
【００７２】
なお、クライアント側の構成、すなわちＣＰＵ、デコーダ処理能力、ディスプレイ構成等に応じた最適な符号化データ、あるいはクライアントの希望する最適な符号化データの態様については、符号化データの送信以前にサーバクライアント間で実行する制御情報伝送処理、すなわちＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）による情報交換によってサーバがクライアントから取得する。制御部１０１は、取得情報に基づいて記憶部１０３からクライアントに適した符号化データ抽出処理を実行し、抽出データに基づいて通信パケットが生成される。これらの処理の詳細については、後述する。
【００７３】
本実施例において、記憶部１０３には、ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００符号化データが格納される。エンコーダ（符号化部）１０２は、ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００符号化処理を実行する。
【００７４】
ウェーブレット変換を実行するエンコーダの構成例を図３に示す。これは、幾つかあるウェーブレット変換手法の中で、最も一般的なウェーブレット変換であるオクターブ分割を複数レベルに亘って行った例である。この図３の場合は、レベル数が３（レベル１〜レベル３）であり、画像信号を低域と高域に分割し、且つ低域成分のみを階層的に分割する構成を採っている。また図３では、便宜上１次元の信号（例えば画像の水平成分）についてのウェーブレット変換を例示しているが、これを２次元に拡張することで２次元画像信号に対応することができる。
【００７５】
次に動作について説明する。図３に示すウェーブレット変換部への入力画像信号２５０は、まずローパスフィルタ２１１（伝達関数Ｈ０（ｚ））とハイパスフィルタ２１２（伝達関数Ｈ１（ｚ））とによって帯域分割され、得られた低域成分と高域成分は、それぞれ対応するダウンサンプラ２１３、２１４によって、解像度がそれぞれ２分の１倍に間引かれる（レベル１）。この時の出力がＬ成分２５１とＨ成分２５６の２つである。ここで、上記Ｌは低域（Ｌｏｗ）、Ｈは高域（Ｈｉｇｈ）を示す。この図３のローパスフィルタ２１１、ハイパスフィルタ２１２、及び２個のダウンサンプラ２１３、２１４によってレベル１の回路部２１０が構成されている。
【００７６】
ダウンサンプラ２１３、２１４によりそれぞれ間引かれた信号の低域成分、すなわちダウンサンプラ２１３からの信号のみが、さらに、レベル２の回路部２２０のローパスフィルタ及びハイパスフィルタによって帯域分割され、それぞれ対応するダウンサンプラによって、解像度をそれぞれ２分の１倍に間引かれる（レベル２）。これらのレベル２のローパスフィルタ、ハイパスフィルタ及びダウンサンプラから成る回路部２２０としては、上記レベル１のローパスフィルタ２１１、ハイパスフィルタ２１２及びダウンサンプラ２１３、２１４から成る回路部２１０と同様な構成が用いられる。
【００７７】
このような処理を所定のレベルまで行うことで、低域成分を階層的に帯域分割した帯域成分が順次生成されていくことになる。レベル２で生成された帯域成分は、ＬＬ成分２５２とＬＨ成分２５５である。図３はレベル３まで帯域分割する例が示されており、レベル２の回路部２２０のローパスフィルタ側のダウンサンプラからの出力が、上記回路部２１０と同様な構成のレベル３の回路部２３０に供給されている。このようにレベル３まで帯域分割した結果、ＬＬＬ成分２５３、ＬＬＨ成分２５４、ＬＨ成分２５５、Ｈ成分２５６が生成される。
【００７８】
図４は、レベル３まで２次元画像を帯域分割した結果得られる帯域成分を図示したものである。この図４に示すＬ及びＨの表記法は、１次元信号を扱った図３でのＬ及びＨの表記法とは異なる。すなわち図４では、先ずレベル１の帯域分割（水平・垂直方向）により４つの成分ＬＬ、ＬＨ、ＨＬ、ＨＨに分かれる。ここでＬＬは水平・垂直成分が共にＬであること、ＬＨは水平成分がＨで垂直成分がＬであることを意味している。次に、ＬＬ成分は再度帯域分割されて、ＬＬＬＬ、ＬＬＨＬ、ＬＬＬＨ、ＬＬＨＨが生成される。さらに、ＬＬＬＬ成分は再度帯域分割されて、ＬＬＬＬＬＬ、ＬＬＬＬＨＬ、ＬＬＬＬＬＨ、ＬＬＬＬＨＨが生成される。
【００７９】
なお、ウェーブレット変換処理においては、プログレッシブ順序でのプログレッション符号化処理が実行可能である。すなわち空間解像度によるプログレッシブ、あるいはＳＮＲ（Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）、すなわち画質によるプログレッシブ、あるいはカラー成分（ＲＧＢやＹＣｂＣｒ）によるプログレッシブ等、様々なプロックレッション態様に応じた階層符号化処理が可能である。
【００８０】
プログレッション符号化とは、インターネットの画像配信等において多用される符号化処理であり、データ受信端末側では、例えば粗い画像データを先に出力し、順次、細かい画像を出力して表示するなどの段階的な復号表示処理を可能とするものである。
【００８１】
例えば、プログレッション符号化の一例として、粗い画像に対応する低周波画像データの符号化データから精細な画像に対応する高周波画像データの符号化データを生成する。データの復号、表示を実行する端末では、低周波画像データの符号化データの復号、表示処理をまず実行することで、短時間でディスプレイに粗い概略画像を表示することが可能となり、その後、高周波領域の符号化データを復号し、表示することで、徐々に精細な画像を表示することが可能となる。
【００８２】
プログレッション符号化としては、異なる解像度の段階的処理構成の他に、ＳＮＲ（Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）、すなわち画質を複数段に設定した構成として、低ＳＮＲ（低画質）の符号化データから高ＳＮＲ（高画質）を区別して符号化する構成、さらにカラー成分（ＲＧＢやＹＣｂＣｒ）によるプログレッション、すなわち、カラー成分（ＲＧＢやＹＣｂＣｒ）毎の符号化を実行する構成等がある。
【００８３】
ウェーブレット変換によるデータ符号化を実行するエンコーダにおける最終処理は、生成した符号化ビットストリームを所定のプログレッションに対応した符号列に並び替える処理である。ＪＰＥＧ２０００では、５種類のプログレッションタイプが規定されている。その中で、代表的なものにＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）と、ＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）がある。
【００８４】
ＬＲＣＰ符号化データ列は、符号化データ列を順次復号することで、解像度を一定にし、画質を徐々に向上させていくプログレッション復号が可能となる。一方、ＲＬＣＰは、画質を均一に保って解像度を徐々に拡大させるプログレッション復号が可能となる。
【００８５】
本実施例におけるデータ送信装置としてのサーバは、例えば上述のＬＲＣＰまたはＲＬＣＰに対応する符号列でウェーブレット変換データを保持する。サーバがＬＲＣＰまたはＲＬＣＰのいずれのデータを保持しているかについての情報、およびその他の符号化データに関する符号化処理態様情報について、符号化データの送信以前にサーバクライアント間で実行する制御情報伝送処理、すなわちＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）による情報交換の際に、クライアント側に通知する処理を実行する。これらの処理の詳細については後述する。
【００８６】
図２に示すエンコーダ１０２は、上述したウェーブレット変換処理を実行する。エンコーダ１０２によって符号化されたデータは、記憶部１０３に格納される。図５に記憶部１０３に格納する符号化データ構成を示す。
【００８７】
図５に示す符号化データ構成について説明する。符号化データは、符号データの始まりを示すＳＯＣ（Ｓｔａｒｔ ｏｆ Ｃｏｄｅ ｓｔｒｅａｍ）マーカで始まり、符号化パラメータや量子化のパラメータ、プログレッシブ順序などが記述されたメインヘッダ（ＭＨ：Ｍａｉｎ Ｈｅａｄｅｒ）が続き、その後に符号化データが続く。この符号化データが階層構造を持っている。符号化データの最後尾に符号データの終了を示すＥＯＣ（Ｅｎｄ ｏｆ Ｃｏｄｅ ｓｔｒｅａｍ）マーカが設定される。
【００８８】
通信パケット生成手段としての通信パケット処理部１０４は、記憶部１０３内の符号化データを解析して、データ内容に応じて区切りを決定し、通信パケットの生成処理を実行する。通信パケット処理部１０４は、記憶部１０３内に格納された符号化データのメインヘッダを参照して、符号化データのプログレッシブ順序情報やレイヤ数、カラー成分に関する情報を取得する。このフィールド情報を読み取ることによりどういう階層により構成されているかを解析する。階層レベルの構成方法は、前述したように、解像度によるプログレッシブ、ＳＮＲ（Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）、すなわち画質によるプログレッシブ、カラー成分（ＲＧＢやＹＣｂＣｒ）によるプログレッシブ等がある。
【００８９】
通信パケット生成手段としての通信パケット処理部１０４は、データ送信先としてのクライアント構成に応じて、記憶部１０３内に格納された符号化データの抽出処理、さらには、符号化データのプログレッシブ順序等の並び替え処理等を行なった後、通信パケットに格納する処理を実行する。これらの処理の詳細については後述する。生成された通信パケットはデータ送受信部（ネットワークＩ／Ｆ）１０５を介してクライアントに送信される。
【００９０】
なお、データ受信装置としてのクライアントはＰＣ、携帯端末等によって構成され、図２に示す構成において、エンコーダ１０２をデコーダに置き換えた構成を持つ。なお、データ送信装置としてのサーバ、およびデータ受信装置としてのクライアントの具体的なハードウェア構成例については、後段で説明する。
【００９１】
次に、符号化データの送信以前にサーバクライアント間で実行する制御情報伝送処理、すなわちＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）による情報交換処理の詳細について説明する。
上述したように、データ送信装置としてのサーバは、データ受信装置としてのクライアント側の構成（処理能力）に応じた最適な符号化データ、あるいはクライアントの希望する最適な符号化データの態様についての情報を取得し、取得情報に基づいて、クライアントに応じた最適態様の符号化データを送信する。
【００９２】
このための情報取得処理が、符号化データの送信以前にサーバクライアント間で実行する制御情報伝送処理、すなわちＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）による情報交換処理である。この情報交換処理は、サーバからクライアントに対するサーバの保持する符号化データ態様情報（サーバ保持データ態様識別情報）の提供処理と、クライアントからサーバに対する希望する符号化データ態様情報（要求データ態様識別情報）の送信処理とを含む処理によって構成される。
【００９３】
なお、サーバはウェーブレット変換に基づくＪＰＥＧ２０００に従った階層符号化データを記憶部１０３（図２参照）に格納し、その格納符号化データは、図６に示す構成であるものとする。符号化パラメータや量子化のパラメータ、プログレッシブ順序などが記述されたメインヘッダ（ＭＨ：Ｍａｉｎ Ｈｅａｄｅｒ）に続いて符号化データが所定の符号化列に従って並んだ構成を持つ。
【００９４】
図６に示すウェーブレット変換符号化データは、１フレームあたりのＪＰ２パケット構成を示す。前述したＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）符号化列であり、符号化データ列を順次復号することで、画質を均一に保って解像度を徐々に拡大させるプログレッション復号を可能とした符号化データ列である。図６に示すＲＬＣＰ符号化データは、ウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化し、３つのコンポーネント（ＹＵＶ）で圧縮し、ＪＰＥＧ２０００データフォーマットに従ったＪＰ２パケットがＲＬ順に並ぶ符号化列設定である。
【００９５】
図６に示すようにウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化したＲＬＣＰ符号化データは、Ｒ＝５、Ｌ＝４の設定であり、ＲＬ５４と示す。Ｒ（Ｒｅｓｏｌｕｔｉｏｎ）はウェーブレット変換回数に相当し、Ｌはレイヤ数に相当する。図６に示す構成では、サーバは、１コンポーネント毎に１フレームあたり２４の符号化データ格納ＪＰ２パケット（（Ｒ０，Ｌ０）〜（Ｒ５，Ｌ３））を保有することになる。
【００９６】
なお、ＪＰ２パケットは、ネットワークを介して送信する通信パケットとは異なる。本明細書ではサーバの記憶部１０３（図２参照）に格納するＪＰＥＧ２０００符号化データの単位データをＪＰ２パケットと表現し、ネットワークを介して送信するパケットを通信パケットと表現する。
【００９７】
なおウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化するとは、５つの異なる解像度（Ｒ：Ｒｅｓｏｌｕｔｉｏｎ）情報ブロックＲ０〜Ｒ５を持ち、各解像度情報ブロック毎に４レイヤ（Ｌ：Ｌａｙｅｒ）の符号化データブロックを持つことを意味する。解像度Ｒ５は７２０×４８０画素の解像度、Ｒ４は３６０×２４０画素の解像度に相当し、Ｒ０は最低解像度画像情報に相当する。レイヤは、同一の解像度データにおける粗い画像データ（低周波画像データ）〜精細な画像データ（高周波画像データ）に対応する。ここでは、各解像度毎に４つのレイヤが設定されている。また、３つのコンポーネント（ＹＵＶ）それぞれに図６に示すＲＬＣＰ符号化列が存在する。
【００９８】
例えばクライアントが、サーバから図６に示す符号化データ列を受信した場合、（Ｒ０，Ｌ０）のＪＰ２パケットを復号することで、最低解像度において粗い画像データ（低周波画像データ）が表示され、順次、（Ｒ０，Ｌ１）〜（Ｒ５，Ｌ３）の復号、表示処理を実行することで、高解像度の精細な画像データ（高周波画像データ）が表示されることになる。
【００９９】
しかし、クライアントの有するディスプレイが７２０×４８０画素の解像度を持つものでなければ、Ｒ５に含まれるＪＰ２パケットの復号処理は無駄となってしまう。また、１画素あたりの表示可能なビット情報が低いディスプレイを持つクライアントが高いレイヤの高周波画像データを取得して復号処理を行なってもディスプレイに復号データに基づく高精細画像を表示することは不可能であり、処理の意味が無い。また、クライアント側のデコード処理構成によっても処理可能な符号化データは異なることになる。従って、クライアント構成に適した最適な符号化データ列を抽出して送信するために、ＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）によるサーバとクライアント間の情報交換処理を実行する。
【０１００】
図７にサーバクライアント間で実行するＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従った制御情報交換処理、および情報交換後の符号化データの送信に至るまでの処理シーケンス図を示す。以下、図７に示す処理シーケンスに従って、処理の詳細について説明する。
【０１０１】
ステップＳ１１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０１０２】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ１２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。ＳＤＰの記述にサーバ保持データ態様識別情報が含まれる。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットを図８に示す。
【０１０３】
［ｖ＝０］はバージョン情報＝０であることを示す。［ｏ＝− ２８９０ｘｘｘ４２ｘｘ ２８ｘｘｘ４２ｘｘ７ ＩＮ ＩＰ４ ４ｘ．ｘ７．１ｘｘ．７ｘ］は、セッションＩＤ、ＩＰバージョン４、ＩＰアドレス情報である。［ｓ＝ＲＴＳＰ ｓｅｓｓｉｏｎ］はＲＴＳＰに従ったプロトコルであることを示す。［ｕ＝ｒｔｓｐ：／／ｖｏｄｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｓｄｐ］は、サーバ内におけるコンテンツ対応のＳＤＰファイルの格納ロケーションを示す情報である。［ｔ＝０ １２３４］は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）による開始時刻＝０、および終了時刻１２３４を示している。［ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ７８］は、メディア情報であり、ビデオ情報をＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）に従って伝送可能であることを示す。［ａ＝ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／ｖｏｄｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｍｊ２］は、サーバ内におけるＪＰＥＧ２００符号化データコンテンツ（ＶｉｄｅｏＡ）の格納ロケーションを示す情報である。ｍｊ２はＪＰＥＧ２０００符号化データであることを示している。
【０１０４】
本発明の構成においては、ＳＤＰを拡張して、上述の各情報に、さらに、［ａ＝ｏｒｄｅｒ：ＲＬ５４ ７２０×４８０］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義した。これが、サーバ保持データ態様識別情報である。［ａ＝ｏｒｄｅｒ：ＲＬ５４ ７２０×４８０］は、サーバが保持しているコンテンツの符号化データの態様を示す情報である。すなわち、サーバは、クライアントの要求コンテンツを図６に示すＲＬＣＰ符号化列データとして保持していることを示す情報である。
【０１０５】
ｏｒｄｅｒ：ＲＬ５４は、ウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化したデータをＲＬＣＰ符号化データ列とした構成、すなわち（Ｒ０，Ｌ０），（Ｒ０，Ｌ１）、〜（Ｒ５，Ｌ４）のデータ列として符号化データを有することを示している。７２０×４８０は解像度情報を示している。
【０１０６】
図７に戻り、サーバクライアント間の処理シーケンスの説明を続ける。ステップＳ１２において、クライアントはサーバからのコンテンツ仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰによって取得する。ＳＤＰには、上述したように符号化データ情報として解像度と画質情報、具体的には符号化データ列情報（ＲＬ５４）および解像度情報（７２０×４８０）を取得することができる。
【０１０７】
クライアントは、受信ＳＤＰに含まれるサーバの有する符号化データ情報に基づいて、クライアントが欲しい符号化画像データに応じた要求データ態様識別情報を設定する。すなちわ、本実施例では、クライアントが受信したい１フレーム当たりのＪＰ２パケット数を算出し、ステップＳ１３において、算出値としての［ＪＰ２パケット数／１フレーム］を要求データ態様識別情報として格納した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０１０８】
クライアントにおけるＳＤＰ受信からＰＬＡＹメソッド送信に至るまでの処理について、図９に示すフローを参照して説明する。クライアントは、ステップＳ１０１において、サーバからＳＤＰを受信するとステップＳ１０２において、解像度情報（ここではＡとする）と、ＲＬ情報の各値をＳＤＰから取得する。
【０１０９】
次に、ステップＳ１０３においてクライアントの有するディスプレイ等の情報に基づいて決定される要求解像度Ｂ（Ｘ×Ｙ）を取得し、ステップＳ１０４において、ＳＤＰから取得したサーバの保有する符号化データの解像度Ａとクライアント要求解像度Ｂを比較する。
【０１１０】
Ａ≦Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像を表示可能であり、サーバの保有する符号化データを復号してクライアントにおいて表示可能であるので、ステップＳ１０６に進む。一方、Ａ＞Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像は表示できないので、ステップＳ１０５において、解像度ＡをＡ／２とする更新処理を実行する。解像度ＡをＡ／２とする更新処理はＲ＝Ｒ−１とする更新処理に相当する。この更新処理をステップＳ１０４の判定条件Ａ＞ＢがＮｏと判定されるまで実行する。
【０１１１】
Ａ＞Ｂの判定がＮｏとなると、ステップＳ１０６において、クライアントが受信したい１フレーム当たりのＪＰ２パケット数を算出する。［ＪＰ２パケット数／１フレーム］を［Ｘ−Ｐｒｉｏｒｉｔｙ］と呼ぶことにする。［Ｘ−Ｐｒｉｏｒｉｔｙ］の算出式は以下の式（式１）に示す通りである。
Ｘ−Ｐｒｉｏｒｉｔｙ＝（ウェーブレット数＋１）×レイヤ数・・（式１）
【０１１２】
つまり、ウェーブレット数３、レイヤ４とすると、Ｘ−Ｐｒｉｏｒｉｔｙの値は１６となる。このＸ−Ｐｒｉｏｒｉｔｙの値は、クライアントの要求する解像度に応じた１フレームあたりのＪＰ２パケット数に相当する値である。
【０１１３】
クライアントは、ステップＳ１０７において、算出したＸ−Ｐｒｉｏｒｉｔｙの値を、ＲＴＳＰのプレイ［ＰＬＡＹ］メソッドに追加ヘッダとして格納してサーバに送信する。クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図１０（ａ）に示す。
【０１１４】
［ＰＬＡＹ ｒｔｓｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｍｊ２ ＲＴＳＰ／１．０］は、要求コンテンツであるビデオ情報（ＶｉｄｅｏＡ）の再生要求、すなわちプレイメソッドであることを示す情報である。［Ｃｓｅｑ： ４］は、通信シーケンス番号である。［Ｓｅｓｓｉｏｎ： １２３４５６７８］は、セッション番号を示す。［Ｘ−Ｐｒｉｏｒｉｔｙ： １６］は、本発明構成において、新たに定義したヘッダであり、上記式（式１）によって算出するクライアントの要求する［ＪＰ２パケット数／１フレーム］を示す値でありこれが１６であることを示している。
【０１１５】
図１０（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。［ＲＴＳＰ／１．０ ２００ ＯＫ］は受信確認であることを示す。［Ｃｓｅｑ： ４］は、通信シーケンス番号である。［Ｓｅｓｓｉｏｎ： １２３４５６７８］は、セッション番号を示す。
【０１１６】
図７に示すシーケンス図では、ステップＳ１４のＡＣＫ送信において、図１０（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ１５において、符号化データのストリーム配信がクライアントに対して実行される。
【０１１７】
サーバは、クライアントから受信したＰＬＡＹメソッドに格納された［Ｘ−Ｐｒｉｏｒｉｔｙ］、すなわち、クライアントの要求する［ＪＰ２パケット数／１フレーム］に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信する。
【０１１８】
サーバがクライアントからＰＬＡＹメソッドを受信し、ＰＬＡＹメソッドに格納されたクライアントの要求する［ＪＰ２パケット数／１フレーム］すなわち、［Ｘ−Ｐｒｉｏｒｉｔｙ］の値を取得し、取得値に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信するまでの処理の詳細を図１１を参照して説明する。
【０１１９】
まず、ステップＳ２０１においてサーバがクライアントからのコンテンツ再生要求メソッドであるＰＬＡＹメソッドを受信すると、ステップＳ２０２において受信したＰＬＡＹメソッド中から［Ｘ−Ｐｒｉｏｒｉｔｙ］の値、すなわちクライアントの要求する［ＪＰ２パケット数／１フレーム］の値を取得する。
【０１２０】
次にステップＳ２０３において、サーバは記憶部から指定コンテンツに対応する符号化データを先頭データから順次取り出す。記憶部に格納された符号化データは、図６を参照して説明したＲＬＣＰ符号化データ列でありＲ＝５，Ｌ＝４のＲＬ５４符号化データである。
【０１２１】
サーバは、記憶部から取得する符号化データを格納したＪＰ２パケット数をカウントし、ステップＳ２０４において、クライアントから受信したＰＬＡＹメソッドから取得した［Ｘ−Ｐｒｉｏｒｉｔｙ］の値と比較する。記憶部から抽出した符号化データ格納ＪＰ２パケット数が［Ｘ−Ｐｒｉｏｒｉｔｙ］の値と等しくなると、ステップＳ２０５に進み、抽出ＪＰ２パケットをペイロードとした通信パケット、すなわちＲＴＰパケットを生成し、ステップＳ２０６において生成した通信パケットをクライアントに対して送信する。
【０１２２】
例えば、クライアントから受信したＰＬＡＹメソッドから取得した［Ｘ−Ｐｒｉｏｒｉｔｙ］の値が１６、すなわち、クライアントの要求する［ＪＰ２パケット数／１フレーム］が１６である場合には、サーバは、１フレームあたり１６のＪＰ２パケットを抽出してクライアントに送信する。
【０１２３】
なお、上述した説明においては、記憶部から取得する符号化データを格納したＪＰ２パケット数をカウントし、クライアントから受信したＰＬＡＹメソッドから取得した［Ｘ−Ｐｒｉｏｒｉｔｙ］の値と取得ＪＰ２パケット数を比較する処理を実行しているが、予めサーバの保有する符号化データＪＰ２パケットに先頭からシーケンシャルな番号を設定し、設定番号と［Ｘ−Ｐｒｉｏｒｉｔｙ］の値との比較を行なって、設定番号≦Ｘ−Ｐｒｉｏｒｉｔｙ値となるＪＰ２パケットのみを送信対象として選択する処理とすることも可能である。
【０１２４】
サーバが記憶部から抽出し、通信パケットに格納するＪＰ２パケットの構成は、図１２に示すものとなる。図１２に示す例は、クライアントから受信したＰＬＡＹメソッドから取得した［Ｘ−Ｐｒｉｏｒｉｔｙ］の値が１６、すなわち、クライアントの要求する［ＪＰ２パケット数／１フレーム］が１６である場合の例である。
【０１２５】
Ｒ０のブロックには、（Ｒ０，Ｌ０）〜（Ｒ０，Ｌ３）の４つのＪＰ２パケットが含まれ、（Ｒ０，Ｌ０）〜（Ｒ３，Ｌ３）の計１６のＪＰ２パケットがサーバの記憶部から抽出されてクライアントに対する通信パケットのペイロードとして格納されて送信される。サーバは図６を参照して説明したようにＲＬ５４の符号化データ、すなわち１フレームあたり２４のＪＰ２パケットからなる符号化データを保有するが、サーバの保有する（Ｒ４，Ｌ０）〜（Ｒ５，Ｌ３）のＪＰ２パケットは、送信されないことになる。
【０１２６】
この図１２に示す符号化データを受信したクライアントは、（Ｒ０，Ｌ０）〜（Ｒ３，Ｌ３）のＪＰ２パケットを順次復号し、再生することにより、解像度、画質を順次向上させるプログレッシブ再生処理が実行され、クライアントの要求した解像度に応じた画像の再生が可能となる。
【０１２７】
［実施例２］
上述した実施例１においては、クライアントからサーバに対して送信するプレイ［ＰＬＡＹ］メソッド中に設定した要求符号化データ態様を示す要求データ態様識別情報として、前述の式（式１）で定義される［Ｘ−Ｐｒｉｏｒｉｔｙ］、すなわちクライアントの要求する［ＪＰ２パケット数／１フレーム］の算出値を設定する構成とした。次に実施例２として、クライアントからサーバに対して送信するプレイ［ＰＬＡＹ］メソッド中にクライアント側において要求する符号化データのＲＬ値、すなわち解像度（Ｒ：Ｒｅｓｏｌｕｔｉｏｎ）、画質に相当するレイヤ（Ｌ：Ｌａｙｅｒ）の値を格納し、サーバ側がクライアントから受信するプレイ［ＰＬＡＹ］メソッド中のＲＬ値に基づいて、送信するＪＰ２パケットを選択抽出する処理例について説明する。
【０１２８】
図１３に実施例２に対応するサーバクライアント間で実行するＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従った制御情報交換処理、および情報交換後の符号化データの送信に至るまでの処理シーケンス図を示す。以下、図１３に示す処理シーケンスに従って、処理の詳細について説明する。
【０１２９】
なお、サーバ側は、ウェーブレット変換に基づくＪＰＥＧ２０００に従った階層符号化データを記憶部１０３（図２参照）に格納し、その格納符号化データは、実施例１と同様、図６に示す構成であるものとする。すなわち、ＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）符号化列であり、ウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化したＲＬ５４であるものとする。
【０１３０】
図１３の処理シーケンスのステップＳ２１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０１３１】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ２２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットは、先の実施例１と同様のデータ、すなわち図８に示すデータ構成である。すなわち、［ａ＝ｏｒｄｅｒ：ＲＬ５４ ７２０×４８０］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義したデータであり、符号化データ列：ＲＬ５４、解像度：７２０×４８０の符号かデータを保有することを示す情報がクライアントに提示される。
【０１３２】
ステップＳ２２において、クライアントはサーバからサーバ保持データ態様識別情報をＳＤＰによって取得すると、クライアントは、次に、クライアントが受信したい符号化データ情報としてのＲＬ情報を要求データ態様識別情報として決定し、ステップＳ２３において、クライアントが受信したい符号化データのＲＬ値を格納した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０１３３】
クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図１４（ａ）に示す。図１４（ａ）の最下段の行に記載された［ＲＬ：３３］が、本実施例において、新たに定義したヘッダであり、クライアントが受信したい符号化データのＲＬ値がＲＬ３３であることを示している。図１４（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。
【０１３４】
図１３に示すシーケンス図では、ステップＳ２４のＡＣＫ送信において、図１４（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ２５において、符号化データのストリーム配信がクライアントに対して実行される。
【０１３５】
サーバは、クライアントから受信したＰＬＡＹメソッドに格納されたＲＬ値、すなわち、クライアントの要求する符号化データのＲＬ値に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信する。
【０１３６】
サーバがクライアントからＰＬＡＹメソッドを受信し、ＰＬＡＹメソッドに格納されたクライアントの要求する符号化データのＲＬ値を取得し、取得値に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信するまでの処理の詳細を図１５を参照して説明する。
【０１３７】
まず、ステップＳ３０１においてサーバがクライアントからのコンテンツ再生要求メソッドであるＰＬＡＹメソッドを受信すると、ステップＳ３０２において受信したＰＬＡＹメソッド中からクライアントの要求する符号化データのＲＬ値を取得する。
【０１３８】
次にステップＳ３０３において、サーバは符号化データを記憶部から取得する事前処理として、ｋ＝０，ｉ＝１とするパラメータの初期設定を行なう。ｋは、記憶部から取得するＲＬ符号化データの何番目のＲブロックかを示すパラメータであり、Ｒ０であればｋ＝０、Ｒ１であればｋ＝１となる。ｉは、各Ｒブロックの何番目のＪＰ２パケットかを示すパラメータであり、Ｌ０であればｉ＝１、Ｌ１であればｉ＝２となる。
【０１３９】
ステップＳ３０３のパラメータ初期設定が完了すると、ステップＳ３０４に進み、サーバは記憶部から指定コンテンツに対応する符号化データを、設定したパラメータｋ，ｉに従って順次取り出す。記憶部に格納された符号化データは、図６を参照して説明したＲＬＣＰ符号化データ列でありＲ＝５，Ｌ＝４のＲＬ５４符号化データである。初期設定は、ｋ＝０，ｉ＝１であるから、図６に示す符号化データ列のＲ０ブロックからＬ０のＪＰ２パケットが取り出される。
【０１４０】
ステップＳ３０５では、［ｉ≧ＰＬＡＹメソッドからの取得値Ｌ］の判定を実行する。ここでは、クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドに図１４（ａ）の最下段の行に記載された［ＲＬ：３３］が設定されているものとする。すなわちＲ＝３，Ｌ＝３であるとする。
【０１４１】
初期設定値ｉ＝１は、ｉ≧３とならないので、ステップＳ３１１に進み、ｉ＝ｉ＋１のパラメータ更新が実行され、ステップＳ３０４に進み次のＪＰ２パケットが取得される。すなわち、図６に示すＲ０ブロックのＬ１のＪＰ２パケットが取得される。同一のＲブロック中のＪＰ２パケットがｉ≧３となるまで取得され、ｉ≧３となると、次にステップＳ３０６において、［ｋ≧ＰＬＡＹメソッドからの取得値Ｒ］の判定を実行する。ＰＬＡＹメソッドの設定［ＲＬ：３３］によりＬ＝３であるので、初期設定ｋ＝０においては、ステップＳ３０６の判定がＮｏとなり、ステップＳ３１２に進み、ｋ＝ｋ＋１，ｉ＝１とするパラメータ更新が実行される。
【０１４２】
この更新により、パラメータがｋ＝１，ｉ＝１となり、図６に示す符号化データ列のＲ１ブロックのＬ０に相当するＪＰ２パケットが取得される。この処理を順次実行することで、クライアントの指定がＲＬ３３の場合には、図１６に示すようにＲ０〜Ｒ３の各ブロックから、それぞれＬ０〜Ｌ２の３つのＪＰ２パケットが取得されることになる。
【０１４３】
ステップＳ３０５、Ｓ３０６の判定が共にＹｅｓとなり、ＪＰ２パケット抽出処理が完了すると、ステップＳ３０７に進み、抽出ＪＰ２パケットをペイロードとした通信パケット、すなわちＲＴＰパケットを生成し、ステップＳ３０８において生成した通信パケットをクライアントに対して送信する。
【０１４４】
サーバが記憶部から抽出し、通信パケットに格納するＪＰ２パケットの構成は、図１６に示すものとなる。図１６に示す例は、クライアントから受信したＰＬＡＹメソッドから取得したＲＬ値がＲＬ３３である場合の例である。
【０１４５】
Ｒ０のブロックには、（Ｒ０，Ｌ０）〜（Ｒ０，Ｌ２）の３つのＪＰ２パケットが含まれ、（Ｒ０，Ｌ０）〜（Ｒ３，Ｌ２）の計１２のＪＰ２パケットがサーバの記憶部から抽出されてクライアントに対する通信パケットのペイロードとして格納されて送信される。サーバは図６を参照して説明したようにＲＬ５４の符号化データ、すなわち１フレームあたり２４のＪＰ２パケットからなる符号化データを保有するが、サーバの保有する（Ｒ０，Ｌ３），（Ｒ１，Ｌ３），（Ｒ２，Ｌ３），（Ｒ３，Ｌ３）、および（Ｒ４，Ｌ０）〜（Ｒ５，Ｌ３）のＪＰ２パケットは、送信されないことになる。
【０１４６】
この図１６に示す符号化データを受信したクライアントは、（Ｒ０，Ｌ０）〜（Ｒ３，Ｌ２）のＪＰ２パケットを順次復号し、再生することにより、解像度、画質を順次向上させるプログレッシブ再生処理が実行され、クライアントの要求した解像度に応じた画像の再生が可能となる。
【０１４７】
［実施例３］
上述した実施例１および実施例２は、サーバの保有する符号化データ列がＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）であり、クライアントの受信するデータ列もＲＬＣＰ符号化データとした例を示した。しかし、クライアント側のデコード処理機能がＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）に対応したものである場合、ＲＬＣＰのデータを受信すると、クライアント側でデータの配列を変更するなどの処理が必要となる。
【０１４８】
サーバ側からの受信データをＬＲＣＰに変更して送信してもらうように設定することでクライアント側の処理負荷が軽減される。実施例３では、クライアント側からサーバに送信するＰＬＡＹメソッドにおいてＲＬまたはＬＲ指定を行ない、サーバが自己の保有する符号化データの配列を変更して符号化データを送信する処理例について説明する。なお、前述したように、ＬＲＣＰ符号化データ列は、符号化データ列を順次復号することで、解像度を一定にし、画質を徐々に向上させていくプログレッション復号が可能となる。一方、ＲＬＣＰは、画質を均一に保って解像度を徐々に拡大させるプログレッション復号が可能となる。
【０１４９】
図１７に実施例３に対応するサーバクライアント間で実行するＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従った制御情報交換処理、および情報交換後の符号化データの送信に至るまでの処理シーケンス図を示す。以下、図１７に示す処理シーケンスに従って、実施例３の処理の詳細について説明する。
【０１５０】
なお、サーバ側は、ウェーブレット変換に基づくＪＰＥＧ２０００に従った階層符号化データを記憶部１０３（図２参照）に格納し、その格納符号化データは、実施例１および２と同様、図６に示す構成であるものとする。すなわち、ＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）符号化列であり、ウェーブレット変換を５回実行し、各係数を４レイヤにビットプレーン化したＲＬ５４であるものとする。
【０１５１】
図１７の処理シーケンスのステップＳ３１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０１５２】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ３２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットは、先の実施例１、２と同様のデータ、すなわち図８に示すデータ構成である。すなわち、［ａ＝ｏｒｄｅｒ：ＲＬ５４ ７２０×４８０］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義したデータであり、符号化データ列：ＲＬ５４、解像度：７２０×４８０の符号化データを保有することを示す情報がクライアントに提示される。
【０１５３】
ステップＳ３２において、クライアントはサーバからのコンテンツ仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰによって取得すると、クライアントは、クライアントが受信したい符号化データ情報を決定し、ステップＳ２３において、クライアントが受信したい符号化データ情報、すなわち要求データ態様識別情報を格納した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０１５４】
クライアントにおけるＳＤＰ受信からＰＬＡＹメソッド送信に至るまでの処理について、図１８に示すフローを参照して説明する。クライアントは、ステップＳ３２１において、サーバからＳＤＰを受信するとステップＳ３２２において、解像度情報（ここではＡとする）と、ＲＬ情報（ＲＬ５４）の各値をＳＤＰから取得する。
【０１５５】
次に、ステップＳ３２３においてクライアントの有する装置構成、例えばＣＰＵ処理能力、メモリ、利用帯域、デコード仕様、ディスプレイ仕様等の情報に基づいて決定される要求解像度Ｂ（Ｘ×Ｙ）および、ＲＬまたはＬＲ符号化列のいずれか、ＲＬｘｙまたはＬＲｘｙのｘおよびｙを決定する。
【０１５６】
次に、ステップＳ３２４において、ＳＤＰから取得したサーバの保有する符号化データの解像度Ａとクライアント要求解像度Ｂを比較する。Ａ≦Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像を表示可能であり、サーバの保有する符号化データを復号してクライアントにおいて表示可能であるので、ステップＳ３２６に進む。一方、Ａ＞Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像は表示できないので、ステップＳ３２５において、解像度ＡをＡ／２とする更新処理を実行する。解像度ＡをＡ／２とする更新処理はＲ＝Ｒ−１とする更新処理に相当する。この更新処理をステップＳ３２４の判定条件Ａ＞ＢがＮｏと判定されるまで実行する。
【０１５７】
Ａ＞Ｂの判定がＮｏとなると、ステップＳ３２６において、送信要求符号化データとしてのＲＬｘｙまたはＬＲｘｙの設定値（例えばＬＲ３４）を決定する。次に、クライアントは、ステップＳ３２７において、決定したＬＲ３４の値を、ＲＴＳＰのプレイ［ＰＬＡＹ］メソッドに追加ヘッダとして格納してサーバに送信する。クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図１９（ａ）に示す。
【０１５８】
図１９（ａ）の最下段の行に記載された［ＬＲ：３４］が、本実施例において、新たに定義したヘッダであり、クライアントが受信したい符号化データがＬＲＣＰ符号化データでありＬ＝３，Ｒ＝４のＬＲ３４であることを示している。図１９（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。
【０１５９】
図１７に示すシーケンス図では、ステップＳ３４のＡＣＫ送信において、図１９（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ３５において、符号化データＬＲ３４のストリーム配信がクライアントに対して実行される。
【０１６０】
サーバは、クライアントから受信したＰＬＡＹメソッドに格納された要求符号化データ情報、すなわちＬＲ３４に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信する。
【０１６１】
サーバがクライアントからＰＬＡＹメソッドを受信し、ＰＬＡＹメソッドに格納されたクライアントの要求する符号化データ情報としてのＬＲ３４を取得し、取得値に従って、サーバの保有する符号化データからＪＰ２パケットを抽出して通信パケット（ＲＴＰ）に格納してクライアントに送信するまでの処理の詳細を図２０を参照して説明する。
【０１６２】
まず、ステップＳ３４１においてサーバがクライアントからのコンテンツ再生要求メソッドであるＰＬＡＹメソッドを受信すると、ステップＳ３４２において受信したＰＬＡＹメソッド中からクライアントの要求する符号化データ情報：ＬＲ３４を取得する。
【０１６３】
次にステップＳ３４３において、サーバは符号化データを記憶部から取得する事前処理として、ｉ＝０，ｋ＝１とするパラメータの初期設定を行なう。ｉは、記憶部から取得するＲＬ符号化データの何番目のＲブロックかを示すパラメータであり、Ｒ０であればｉ＝０、Ｒ１であればｉ＝１となる。ｋは、各Ｒブロックの何番目のＪＰ２パケットかを示すパラメータであり、Ｌ０であればｋ＝１、Ｌ１であればｋ＝２となる。
【０１６４】
ステップＳ３４３のパラメータ初期設定が完了すると、ステップＳ３４４に進み、サーバは記憶部から指定コンテンツに対応する符号化データを、設定したパラメータｉ，ｋに従って順次取り出す。記憶部に格納された符号化データは、図６を参照して説明したＲＬＣＰ符号化データ列でありＲ＝５，Ｌ＝４のＲＬ５４符号化データである。初期設定は、ｉ＝０，ｋ＝１であるから、図６に示す符号化データ列のＲ０ブロックからＬ０のＪＰ２パケットが取り出される。
【０１６５】
ステップＳ３４５では、［ｉ≧ＰＬＡＹメソッドからの取得値Ｒ］の判定を実行する。ここでは、クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドに図１９（ａ）の最下段の行に記載された［ＬＲ：３４］が設定されているものとする。すなわちＬ＝３，Ｒ＝４であるとする。
【０１６６】
初期設定値ｉ＝０は、ｉ≧４とならないので、ステップＳ３５１に進み、ｉ＝ｉ＋１のパラメータ更新が実行され、ステップＳ３４４に進み、次のＪＰ２パケットが取得される。すなわち、図６に示すＲ１ブロックのＬ０のＪＰ２パケットが取得される。このように、各Ｒブロックの先頭のＪＰ２パケット（Ｌ０）がまず取得される。図２１に（ａ）サーバ保持データと、（ｂ）送信データの対応を示す。
【０１６７】
各Ｒブロック中の先頭のＪＰ２パケットの取得が、ｉ≧４となるまで実行される。ｉ≧４となると、次にステップＳ３４６において、［ｋ≧ＰＬＡＹメソッドからの取得値Ｌ］の判定を実行する。ＰＬＡＹメソッドの設定［ＬＲ：３４］によりＬ＝３であるので、初期設定ｋ＝１においては、ステップＳ３４６の判定がＮｏとなり、ステップＳ３５２に進み、ｋ＝ｋ＋１，ｉ＝０とするパラメータ更新が実行される。
【０１６８】
この更新により、パラメータがｋ＝２，ｉ＝０となり、図６に示す符号化データ列のＲ０ブロックのＬ１に相当するＪＰ２パケットが取得される。この処理を順次実行することで、クライアントの指定がＬＲ３４の場合、図２１に示すようにＬＲ３４のＬＲＣＰ符号化データ配列が設定されることになる。
【０１６９】
ステップＳ３４５、Ｓ３４６の判定が共にＹｅｓとなり、ＪＰ２パケット抽出処理が完了すると、ステップＳ３４７に進み、抽出したＬＲ３４符号化データからなるＪＰ２パケットをペイロードとした通信パケット、すなわちＲＴＰパケットを生成し、ステップＳ３４８において生成した通信パケットをクライアントに対して送信する。
【０１７０】
通信パケットに格納するＪＰ２パケットの構成は、図２１に示すものとなる。図２１に示す例は、クライアントから受信したＰＬＡＹメソッドから取得した要求符号化データ情報がＬＲ３４である場合の例である。
【０１７１】
送信データは、Ｌ０のブロック中にＲ０〜Ｒ４が順次配列され、次に、Ｌ１のブロック中にＲ０〜Ｒ４が順次配列されたＬＲＣＰ構成を持ち、クライアント側の要求ＬＲ３４に従った符号化データ配列となる。
【０１７２】
この図２１に示す符号化データを受信したクライアントは、（Ｌ０，Ｒ０）〜（Ｌ２，Ｒ４）のＪＰ２パケットを順次復号し、再生することにより、解像度、画質を順次向上させるプログレッシブ再生処理が実行され、クライアントの要求に応じた画像の再生が可能となる。
【０１７３】
［実施例４］
上述の実施例１〜３は、いずれも、コンテンツ仕様要求としてのＲＴＳＰのメソッド［ＤＥＳＣＲＩＢＥ］をクライアントからサーバに送信し、その応答としてのＳＤＰをクライアントがサーバから受信して、ＳＤＰに基づいて要求する符号化情報をＰＬＡＹメソッドに格納してサーバに送信する処理構成例を説明した。実施例４では、クライアントが予めサーバの保有するコンテンツの符号化情報を保有している場合の処理例を説明する。すなわち、ＲＴＳＰのメソッド［ＤＥＳＣＲＩＢＥ］、および応答としてのＳＤＰを用いないで、ＰＬＡＹメソッドを直接実行することでクライアントの要求する符号化情報をサーバから受信する処理形態である。
【０１７４】
図２２に実施例４に対応するサーバクライアント間で実行する通信処理シーケンス図を示す。以下、図２２に示す処理シーケンスに従って、実施例４の処理の詳細について説明する。
【０１７５】
図２２の処理シーケンスのステップＳ４１において、クライアントはクライアントが受信したい符号化データ情報、すなわち要求データ態様識別情報を格納した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０１７６】
クライアントが再生要求メソッド［ＰＬＡＹ］に格納する符号化データ情報は、クライアントが予め保持しているサーバのコンテンツデータ情報と、クライアントの構成（ディスプレイ、ＣＰＵ、デコーダ仕様等）の情報に基づいて決定するものであり、例えば上述の実施例１〜３において説明した１フレームあたりのＪＰ２パケット数情報や、解像度情報、あるいはＲＬｘｙまたはＬＲｘｙの設定情報などである。
【０１７７】
要求符号化データ情報を格納した再生要求メソッド［ＰＬＡＹ］をクライアントから受信したサーバは、ステップＳ４２でＡＣＫ送信を実行し、続いて、ステップＳ４３において、再生要求メソッド［ＰＬＡＹ］に格納された要求符号化データ情報に従って抽出生成したＪＰ２パケット列からなる符号化データのストリーム配信をクライアントに対して実行する。
【０１７８】
本方式によれば、ＲＴＳＰのメソッド［ＤＥＳＣＲＩＢＥ］、および応答としてのＳＤＰを適用せず、ＰＬＡＹメソッドを直接実行する構成であるので、効率的な処理が可能となる。
【０１７９】
［実施例５］
上述した実施例はＪＰＥＧ２０００のデータフォーマットに従った符号化データの配信処理例として説明したが、本発明はＪＰＥＧ２０００のデータフォーマットに従った符号化データの配信構成に限らず、様々な符号化データの配信処理において適用可能である。実施例５は、ウェーブレット変換処理による符号化データではあるがＪＰＥＧ２００のデータフォーマットとは異なるフォーマットを持つ符号化データの配信処理例について説明する。
【０１８０】
図２３にサーバクライアント間で実行するＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従った制御情報交換処理、および情報交換後の符号化データの送信に至るまでの処理シーケンス図を示す。以下、図２３に示す処理シーケンスに従って、処理の詳細について説明する。
【０１８１】
ステップＳ５１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０１８２】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ５２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットを図２４に示す。
【０１８３】
図２４のｖ〜ｍまでのデータ構成は、実施例１で図８を参照して説明したデータと同様であるので説明を省略する。［ａ＝ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／ｖｏｄｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｘｘｘ］は、サーバ内におけるコンテンツ（ｖｉｄｅｏＡ）の格納ロケーションを示す情報である。このコンテンツはＪＰＥＧ２０００の符号化データとは異なるフォーマットでの符号化データである。
【０１８４】
本実施例の構成においては、ＳＤＰを拡張して、上述の各情報に、さらに、［ａ＝Ｒ５ ７２０×４８０］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義した。［ａ＝Ｒ５ ７２０×４８０］は、サーバが保持しているコンテンツの符号化データの態様を示す情報である。Ｒ５は、ウェーブレット変換を５回実行した符号化データであることを示し、７２０×４８０は解像度情報を示している。
【０１８５】
図２３に戻り、サーバクライアント間の処理シーケンスの説明を続ける。ステップＳ５２において、クライアントはサーバからのコンテンツ仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰによって取得する。クライアントは、ＳＤＰから符号化データ情報としてＲ５と７２０×４８０を取得することができる。
【０１８６】
クライアントは、受信ＳＤＰに含まれるサーバの有する符号化データ情報に基づいて、クライアントの希望する符号化画像データに応じた要求符号化データ情報を決定する。例えばＲ３に相当する解像度を持つ符号化データを要求したい場合、要求符号化データ情報：Ｒ３を設定した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０１８７】
クライアントにおけるＳＤＰ受信からＰＬＡＹメソッド送信に至るまでの処理について、図２５に示すフローを参照して説明する。クライアントは、ステップＳ５０１において、サーバからＳＤＰを受信するとステップＳ５０２において、解像度情報（ここではＡとする）と、Ｒ情報値をＳＤＰから取得する。
【０１８８】
次に、ステップＳ５０３においてクライアントの有するディスプレイ等の情報に基づいて決定される要求解像度Ｂ（Ｘ×Ｙ）を取得し、ステップＳ５０４において、ＳＤＰから取得したサーバの保有する符号化データの解像度Ａとクライアント要求解像度Ｂを比較する。
【０１８９】
Ａ≦Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像を表示可能であり、サーバの保有する符号化データを復号してクライアントにおいて表示可能であるので、ステップＳ５０６に進む。一方、Ａ＞Ｂであれば、クライアントのディスプレイに解像度Ａ（例えば７２０×４８０）の画像は表示できないので、ステップＳ５０５において、解像度ＡをＡ／２とする更新処理を実行する。解像度ＡをＡ／２とする更新処理はＲ＝Ｒ−１とする更新処理に相当する。この更新処理をステップＳ５０４の判定条件Ａ＞ＢがＮｏと判定されるまで実行する。
【０１９０】
Ａ＞Ｂの判定がＮｏとなると、ステップＳ５０６において、クライアントが受信したい符号化データ態様に対応する要求符号化データ情報を決定する。
【０１９１】
クライアントは、ステップＳ５０７において、決定した要求符号化データ情報をプレイ［ＰＬＡＹ］メソッドに追加ヘッダとして格納してサーバに送信する。クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図２６（ａ）に示す。
【０１９２】
［ＰＬＡＹ ｒｔｓｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｘｘｘ ＲＴＳＰ／１．０］は、要求コンテンツであるビデオ情報（ＶｉｄｅｏＡ）の再生要求、すなわちプレイメソッドであることを示す情報である。ｖｉｄｅｏＡ．ｘｘｘは、実施例１のｖｉｄｅｏＡ．ｍｊ２と異なり、ＪＰＥＧ２０００の符号化データではないことを示している。その他の情報は実施例１と同様であり、説明を省略する。
【０１９３】
図２６（ａ）の最下段の行に記載された［Ｒ：３］が、本実施例において、新たに定義したヘッダであり、クライアントが受信したい符号化データが解像度としてＲ：３に相当する符号化データであることを示している。図２６（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。
【０１９４】
図２３に示すシーケンス図では、ステップＳ５４のＡＣＫ送信において、図２６（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ５５において、クライアントの要求する符号化データ、すなわちＲ３に対応する符号化データが抽出され、生成されたＲＴＰパケットを用いたストリーム配信がクライアントに対して実行される。符号化データ抽出処理は、上述の各実施例において説明した処理と同様の処理として実行される。サーバは、フレーム毎にウェーブレットの低周波成分から順にユーザの要求する解像度まで送信する。符号化データを受信したクライアントは、受信データを復号し、再生する。
【０１９５】
本実施例において説明したようにＪＰＥＧ２０００とは異なるデータフォーマットにおいても、クライアントからの要求に従ってサーバが符号化データを生成、調整してクライアント対応の符号化データ列を生成し送信することが可能である。
【０１９６】
［実施例６］
前述したように、階層符号化が可能な圧縮・伸張方式としては、例えばＭＰＥＧ４とＪＰＥＧ２０００によるビデオストリームをあげることができる。ＭＰＥＧ４ではＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）技術を規格に取り込みプロファイル化する予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。実施例６では、ＭＰＥＧ４による階層符号化データを用いた処理例について説明する。
【０１９７】
ＭＰＥＧ４におけるＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）を用いた階層符号化方式は、ストリーミングアプリケーションに適した圧縮方式であり、ＤＣＴをベースとした動画像圧縮方式に適用可能である。ＦＧＳを適用した階層符号化処理について、図２７を参照して説明する。
【０１９８】
図２７に示すようにＭＰＥＧ４におけるＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）を用いた階層符号化データは、ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）と、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の２層から構成される。ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）は、従来通りの離散コサイン変換と予測符号化に基づいて生成される圧縮データである。フレーム間予測処理のベース情報を持つＩピクチャ、順方向予測で生成されるＰピクチャ、Ｐピクチャ間に挿入されるＢピクチャのＩＰＢ３種類のピクチャ情報によって構成される。
【０１９９】
エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）は、ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）と原画像を元にしてｅｍｂｅｄｄｅｄＤＣＴ圧縮法等を用いて符号化される。ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）のみで最低限の画質を得ることができるが、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）をあわせることにより、より高品質な画質を得ることができる。なお、動画の画質はエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の符号化パラメータと復号時のエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量によって決定する。
【０２００】
ＦＧＳのエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）に含まれる情報は、任意数に分割することが可能である。例えば図２８に示すようにエンハンスメント・レイヤを複数に分割し、ベースレイヤおよび、エンハンスメント・レイヤに含まれるレイヤ１〜５から選択したレイヤのみの情報をサーバからクライアントに用いて復号処理を行なうことが可能である。
【０２０１】
例えば、ベースレイヤおよび、エンハンスメント・レイヤに含まれるレイヤ１〜３、あるいは１〜５のレイヤをクライアントからの要求に応じて選択してクライアントに送信し、クライアント側で受信レイヤに応じて復号することが可能である。ベースレイヤのみでは最低限の画質からなる画像データ再生が可能であり、エンハンスメント・レイヤ１のみではやや高品質な画像、より多くのエンハンスメント・レイヤ情報を適用して復号処理を実行することで、より高画質の画像データを表示することが可能となる。
【０２０２】
このように、クライアントの要求に応じたレイヤ情報をサーバが抽出して送信することで、クライアントの要求に応じた階層符号化情報配信が可能となる。ＭＰＥＧ４におけるＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）を用いた階層符号化データを配信する際、データ送信装置としてのサーバが、データ受信装置としてのクライアント側の要求符号化データ情報を取得し、取得情報に基づいて、クライアントに応じた最適態様の符号化データを送信する処理、すなわち、ＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）による情報交換処理を実行して、要求に従った符号化データ配信処理を行なう処理シーケンスについて、図２９のシーケンス図を参照して説明する。
【０２０３】
ステップＳ６１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０２０４】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ６２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットを図３０に示す。
【０２０５】
図３０のｖ〜ｍまでのデータ構成は、実施例１で図８を参照して説明したデータと同様であるので説明を省略する。［ａ＝ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／ｖｏｄｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｍｐｇ］は、サーバ内におけるコンテンツ（ｖｉｄｅｏＡ．ｍｐｇ）の格納ロケーションを示す情報である。このコンテンツはＭＰＥＧフォーマットでの符号化データである。
【０２０６】
本実施例の構成においては、ＳＤＰを拡張して、上述の各情報に、さらに、［ａ＝ＥＬ：５］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義した。［ＥＬ：５］は、サーバが保持しているコンテンツの符号化データの態様を示す情報である。ＥＬ：５は、ＭＰＥＧ４符号化データのＦＧＳエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）情報を５分割してサーバが格納していることを示す情報である。
【０２０７】
図２９に戻り、サーバクライアント間の処理シーケンスの説明を続ける。ステップＳ６２において、クライアントはサーバからのコンテンツ仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰによって取得する。クライアントは、ＳＤＰから符号化データ情報としてＦＧＳエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の分割情報［ＥＬ：５］を取得することができる。
【０２０８】
クライアントは、受信ＳＤＰに含まれるサーバの有する符号化データ情報に基づいて、クライアントの希望する符号化画像データに応じた要求符号化データ情報を決定する。例えばＦＧＳエンハンスメント・レイヤとしてＥＬ：３に相当する情報の取得を要求したい場合、要求符号化データ情報としてＥＬ：３を設定した再生要求メソッド［ＰＬＡＹ］をサーバに送信する。
【０２０９】
クライアントにおけるＳＤＰ受信からＰＬＡＹメソッド送信に至るまでの処理について、図３１に示すフローを参照して説明する。クライアントは、ステップＳ５５１において、サーバからＳＤＰを受信するとステップＳ５５２において、画質情報、ここではサーバの保持するＭＰＥＧ４符号化データのＦＧＳエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の分割情報［ＥＬ：５］をＳＤＰから取得する。
【０２１０】
次に、ステップＳ５５３においてクライアントの有するＣＰＵ、デコーダ、ディスプレイ等の情報に基づいて要求画質：Ｂを仮設定する。要求画質：Ｂは、ＭＰＥＧ４符号化データのＦＧＳエンハンスメント・レイヤの分割情報［ＥＬ］に対応して設定される値であり０〜５の範囲の値である。ここでは例えばＥＬ値として３が要求画質：Ｂに相当するとする。ステップＳ５５４において、ＳＤＰから取得したサーバの保有する符号化データのエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の分割情報［ＥＬ：５］と要求画質：Ｂ（＝３）を比較する。
【０２１１】
要求画質を超えるデータは、伝送処理あるいは復号処理の無駄になるので、ＥＬ＞Ｂである場合は、ステップＳ５５５において、ＥＬ＝ＥＬ−１とする更新処理を実行する。この更新処理をステップＳ５５４の判定条件ＥＬ＞ＢがＮＯと判定されるまで実行する。
【０２１２】
ＥＬ＞Ｂの判定がＮｏとなると、ステップＳ５５６において、クライアントが受信したい符号化データ態様に対応する要求符号化データ情報を決定する。ここでは、要求画質：Ｂに相当するＥＬ：３と決定するものとする。
【０２１３】
クライアントは、ステップＳ５５７において、決定した要求符号化データ情報をプレイ［ＰＬＡＹ］メソッドに追加ヘッダとして格納してサーバに送信する。クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図３２（ａ）に示す。
【０２１４】
［ＰＬＡＹ ｒｔｓｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｍｐｇ ＲＴＳＰ／１．０］は、要求コンテンツであるビデオ情報（ＶｉｄｅｏＡ）の再生要求、すなわちプレイメソッドであることを示す情報である。ｖｉｄｅｏＡ．ｍｐｇは、ＭＰＥＧ符号化データであることを示している。その他の情報は実施例１と同様であり、説明を省略する。
【０２１５】
図３２（ａ）の最下段の行に記載された［ＥＬ：３］が、本実施例において、新たに定義したヘッダであり、クライアントが受信したい符号化データが、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の分割データとして［ＥＬ：３］のレベルまでのデータであることを示している。図３２（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。
【０２１６】
図２９に示すシーケンス図では、ステップＳ６４のＡＣＫ送信において、図３２（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ６５において、クライアントの要求する符号化データ、すなわちＭＰＥＧ符号化データを構成するベースレイヤのデータと、ＥＬ：３に対応するエンハンスメント・レイヤの符号化データが抽出され、抽出データをペイロードとして生成されたＲＴＰパケットを用いたストリーム配信がクライアントに対して実行される。符号化データ抽出処理は、上述の各実施例において説明した処理と同様の処理として実行される。
【０２１７】
［実施例７］
上述した実施例６においては、ＭＰＥＧ４におけるＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）を用いた階層符号化データを配信する際、データ送信側のサーバが予めエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の分割を実行し、送信データに含める分割レイヤの指定をクライアント側が実行する構成例を説明した。エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）は任意の箇所で分割することができる。
【０２１８】
サーバがクライアントに対して送信するエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）のデータ量を決定するために、配信データ（コンテンツ）の画質情報の１つである信号対雑音比の情報としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）を用いる構成例を実施例７として説明する。
【０２１９】
前述したように、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）は、ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）と原画像を元にしてｅｍｂｅｄｄｅｄＤＣＴ圧縮法等を用いて符号化されるデータである。ベースレイヤ（Ｂａｓｅ Ｌａｙｅｒ）のみで最低限の画質を得ることができるが、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）をあわせることにより、より高品質な画質を得ることができる。画質はエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量が多ければ向上する。すなわち、画質はエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量によって決定する。画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値はエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量が多ければ上昇する。
【０２２０】
図３３に、ベースレイヤ（ＢＬ：Ｂａｓｅ Ｌａｙｅｒ）と、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量に応じた画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の対応を示す。図３３に示すように、このように、ベースレイヤ（ＢＬ：Ｂａｓｅ Ｌａｙｅｒ）のみのデータ（ＥＬ＝０）は、ＰＳＮＲ値が低いが、エンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の付加量を増加させるに従って、ＰＳＮＲ値が上昇し画質が向上する。
【０２２１】
本実施例では、クライアントがＰＳＮＲ値を指定して、サーバが指定ＰＳＮＲ値に応じて、クライアントに対して送信するエンハンスメント・レイヤの情報量を決定してデータ送信を実行するものである。
【０２２２】
本実施例のサーバクライアント間で実行されるデータ通信処理シーケンスについて、図３４のシーケンス図を参照して説明する。ステップＳ７１において、クライアントはＲＴＳＰに規定されたメソッド［ＤＥＳＣＲＩＢＥ］をサーバに送信する。デスクライブ［ＤＥＳＣＲＩＢＥ］は、コンテンツの仕様要求を実行するためのメソッドであり、例えばコンテンツ識別子を送信してコンテンツの仕様要求を行なうものである。
【０２２３】
サーバは、メソッド［ＤＥＳＣＲＩＢＥ］をクライアントから受信すると、ステップＳ７２において、コンテンツの仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に従ってクライアントに伝える処理を実行する。サーバからクライアントに通知するＳＤＰに従ったデータフォーマットを図３５に示す。
【０２２４】
図３５のｖ〜ａまでのデータ構成は、実施例６の図３０に示すデータと同様である。本実施例の構成においては、ＳＤＰを拡張して、上述の各情報に、さらに、［ａ＝ＰＳＮＲ：４５］を新たなコンテンツ属性（Ａｔｔｒｉｂｕｔｅ）として定義した。［ＰＳＮＲ：４５］は、サーバが保持しているコンテンツの符号化データの態様を示す情報である。ＰＳＮＲ：４５は、サーバの保持するＭＰＥＧ４符号化データのＦＧＳエンハンスメント・レイヤ（Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ）の情報を全て復号して得られる最高画質情報としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値を示す。
【０２２５】
図３４に戻り、サーバクライアント間の処理シーケンスの説明を続ける。ステップＳ７２において、クライアントはサーバからのコンテンツ仕様情報、すなわちサーバ保持データ態様識別情報をＳＤＰによって取得する。クライアントは、ＳＤＰから符号化データ情報としてサーバの保持するＭＰＥＧ４符号化データの最高画質情報としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値［ＰＳＮＲ：４５］を取得することができる。
【０２２６】
クライアントは、受信ＳＤＰに含まれるサーバの有する符号化データ情報に基づいて、クライアントの希望する符号化画像データに応じた要求符号化データ情報を決定する。例えば画質情報としてのＰＳＮＲの値として［ＰＳＮＲ：３０］を設定する。この値は、クライアント装置のＣＰＵ、デコーダ、ディスプレイ等の仕様等に基づいて決定する。
【０２２７】
クライアントにおけるＳＤＰ受信からＰＬＡＹメソッド送信に至るまでの処理について、図３６に示すフローを参照して説明する。クライアントは、ステップＳ５７１において、サーバからＳＤＰを受信するとステップＳ５７２において、画質情報、ここではサーバの保持するＭＰＥＧ４符号化データの最高画質指標値：Ａ［ＰＳＮＲ：４５］をＳＤＰから取得する。
【０２２８】
次に、ステップＳ５７３においてクライアントの有するＣＰＵ、デコーダ、ディスプレイ等の情報に基づいて要求画質指標値：Ｂ［ＰＳＮＲ：３０］を設定する。ステップＳ５７４において、ＳＤＰから取得したサーバの保有するＭＰＥＧ４符号化データの最高画質指標値：Ａ［ＰＳＮＲ：４５］と、要求画質指標値：Ｂ［ＰＳＮＲ：３０］とが一致するか否かを判定する。
【０２２９】
要求画質を超えるデータは、伝送処理あるいは復号処理の無駄になるので、Ａ≠Ｂである場合は、ステップＳ５７５において、Ａ＝Ｂとする更新処理を実行する。Ａ＝Ｂが成立すると、ステップＳ５７６において、クライアントが受信したい符号化データ態様に対応する要求符号化データ情報を決定する。ここでは、要求画質：Ｂに相当するＰＳＮＲ：３０と決定するものとする。
【０２３０】
クライアントは、ステップＳ５７７において、決定した算要求符号化データ情報をプレイ［ＰＬＡＹ］メソッドに追加ヘッダとして格納してサーバに送信する。クライアントからサーバに対して送信するＲＴＳＰのプレイ［ＰＬＡＹ］メソッドのデータ構成を図３７（ａ）に示す。［ＰＬＡＹ ｒｔｓｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓ／ｖｉｄｅｏＡ．ｍｐｇ ＲＴＳＰ／１．０］は、要求コンテンツであるビデオ情報（ＶｉｄｅｏＡ）の再生要求、すなわちプレイメソッドであることを示す情報である。ｖｉｄｅｏＡ．ｍｐｇは、ＭＰＥＧ符号化データであることを示している。その他の情報は実施例１と同様であり、説明を省略する。
【０２３１】
図３７（ａ）の最下段の行に記載された［ＰＳＮＲ：３０］が、本実施例において、新たに定義したヘッダであり、クライアントが受信したい符号化データが、画質指標値としてＰＳＮＲ：３０を有する画像再生可能なデータであることを示している。図３７（ｂ）は、クライアントからＲＴＳＰのプレイ［ＰＬＡＹ］メソッドを受信したサーバがクライアントに対して送信する受信確認［ＡＣＫ］データである。
【０２３２】
図３４に示すシーケンス図では、ステップＳ７４のＡＣＫ送信において、図３７（ｂ）に示すＡＣＫデータがクライアントに送信され、続いて、ステップＳ７５において、クライアントの要求する符号化データ、すなわちＭＰＥＧ符号化データを構成するベースレイヤのデータと、画質指標値としてＰＳＮＲ：３０を有する画像再生可能なエンハンスメント・レイヤの符号化データが抽出され、抽出データをペイロードとしたＲＴＰパケットを用いたストリーム配信がクライアントに対して実行される。
【０２３３】
サーバ側では、クライアントから受信するＰＳＮＲ値に応じて、先に説明した図３３のＥＬ付加量とＰＳＮＲとの対応関係に基づいて、ＥＬ付加量を決定して、決定したＥＬデータとベースレイヤ（ＢＬ）データとを通信パケットのペイロードとして格納し、クライアントに送信する。
【０２３４】
なお、実施例６、７においてＭＰＥＧ４によるＦＧＳ（Ｆｉｎｅ Ｇｒａｎｕｌａｒ Ｓｃａｌａｂｉｌｉｔｙ）技術を適用した圧縮処理はＤＣＴをベースとした動画像圧縮方式であるが、ＭＰＥＧデータフォーマットに限らず、例えば他の画像圧縮フォーマットを規定しているＪＶＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｔｅａｍ）を適用した場合でも、上述の処理と同様、クライアント要求に従って階層符号化データの選択、送信処理を実行することが可能である。
【０２３５】
［データ送受信装置構成例］
図３８に、上述の実施例で述べた一連の処理を実行するサーバおよびクライアントに対応するデータ送信装置、データ受信装置の構成例を示す。本発明のシステムで送受信されるデータは、階層符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはＩＰパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０２３６】
図３８に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０２３７】
コーデック８５１は、図３８に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、階層符号化処理がなされて記憶部としてのＨＤＤ８５８に格納される。サーバはクライアントからの要求に応じて、制御部としてのＣＰＵ８５６の制御の下、記憶部から選択的に符号化データを抽出し、必要に応じて配列の調整を実行し、パケット生成処理（パケタイズ）を実行し、最終的に階層符号化データをペイロードとしたＩＰパケットを生成する。生成されたＩＰパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、例えばＩＰパケットのヘッダに設定された宛先アドレスに配信される。
【０２３８】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを階層符号化してネットワークインタフェース８５２を介してネットワークに出力するソフトウェアによる処理を可能とした構成としてもよい。
【０２３９】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５９上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された階層符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０２４０】
上述の実施例における符号化処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０２４１】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメモリにロードして実行することも可能である。
【０２４２】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２４３】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２４４】
例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０２４５】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０２４６】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０２４７】
【発明の効果】
以上説明してきたように、本発明の構成によれば、階層符号化データの送信処理を実行するサーバと、サーバから階層符号化データを受信するクライアントからなるサーバクライアントシステムにおいて、クライアントからサーバに対して送信するデータ要求メッセージに、クライアントの要求する階層符号化データ態様を示す要求データ態様識別情報を格納して送信し、サーバが要求データ態様識別情報に基づいて、クライアント対応の符号化データを抽出または生成してクライアントに送信する処理を実行する構成としたので、クライアントの処理能力等に応じた最適なデータの送信が可能になる。
【０２４８】
また、本発明の構成によれば、サーバは、記憶部に格納する唯一の符号化データから、クライアントの要求に応じてデータ抽出により様々な構成のデータを送信データとすることが可能となるので、サーバは様々なタイプのデータを複数格納する必要がなく効率的な処理が可能となる。
【０２４９】
さらに、本発明の構成によれば、クライアントは、データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行し、サーバが応答として、サーバ保持データ態様識別情報を格納した応答メッセージをクライアントに送信し、クライアントは、サーバ保持データ態様識別情報に基づいて、クライアントの要求する階層符号化データ態様を決定することが可能となり、サーバが確実に保有する範囲でのデータ要求が可能となる。
【図面の簡単な説明】
【図１】本発明の適用可能なネットワーク構成例を示す図である。
【図２】本発明のデータ送信装置の構成例を示す図である。
【図３】ウェーブレット変換による符号化処理構成例を示す図である。
【図４】ウェーブレット変換処理を説明する図である。
【図５】本発明のデータ送信装置の有する符号化データ構成を説明する図である。
【図６】本発明のデータ送信装置の有するＪＰＥＧ２００符号化データの構成例を説明する図である。
【図７】本発明の第１実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図８】本発明の第１実施例におけるサーバからクライアントに対して送信するメッセージデータ例を示す図である。
【図９】本発明の第１実施例のクライアントにおけるＳＤＰ受信からプレイメソッド送信までの処理を示すフロー図である。
【図１０】本発明の第１実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図１１】本発明の第１実施例のサーバにおけるＰＬＡＹメソッド受信から符号化データ送信までの処理を示すフロー図である。
【図１２】本発明の第１実施例におけるサーバからクライアントに送信される符号化データの構成を示す図である。
【図１３】本発明の第２実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図１４】本発明の第２実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図１５】本発明の第２実施例のサーバにおけるＰＬＡＹメソッド受信から符号化データ送信までの処理を示すフロー図である。
【図１６】本発明の第２実施例におけるサーバからクライアントに送信される符号化データの構成を示す図である。
【図１７】本発明の第３実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図１８】本発明の第３実施例のクライアントにおけるＳＤＰ受信からプレイメソッド送信までの処理を示すフロー図である。
【図１９】本発明の第３実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図２０】本発明の第３実施例のサーバにおけるＰＬＡＹメソッド受信から符号化データ送信までの処理を示すフロー図である。
【図２１】本発明の第３実施例におけるサーバからクライアントに送信される符号化データの構成を示す図である。
【図２２】本発明の第４実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図２３】本発明の第５実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図２４】本発明の第５実施例におけるサーバからクライアントに対して送信するメッセージデータ例を示す図である。
【図２５】本発明の第５実施例のクライアントにおけるＳＤＰ受信からプレイメソッド送信までの処理を示すフロー図である。
【図２６】本発明の第５実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図２７】ＭＰＥＧによる階層符号化データ構成を説明する図である。
【図２８】ＭＰＥＧによる階層符号化データの分割例を説明する図である。
【図２９】本発明の第６実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図３０】本発明の第６実施例におけるサーバからクライアントに対して送信するメッセージデータ例を示す図である。
【図３１】本発明の第６実施例のクライアントにおけるＳＤＰ受信からプレイメソッド送信までの処理を示すフロー図である。
【図３２】本発明の第６実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図３３】ＭＰＥＧ階層符号データのエンハンスメント・レイヤの付加量と画質（ＰＳＮＲ）の対応を示す図である。
【図３４】本発明の第７実施例におけるサーバクライアント間の通信シーケンスを示す図である。
【図３５】本発明の第７実施例におけるサーバからクライアントに対して送信するメッセージデータ例を示す図である。
【図３６】本発明の第７実施例のクライアントにおけるＳＤＰ受信からプレイメソッド送信までの処理を示すフロー図である。
【図３７】本発明の第７実施例におけるクライアントの送信メッセージおよびサーバからの応答データ例を示す図である。
【図３８】データ送信装置およびデータ受信装置のシステム構成例を示す図である。
【符号の説明】
１１ サーバ
１２ ネットワーク
１３ 基地局
２１，２２，２３ クライアント
１００ サーバ
１０１ 制御部
１０２ エンコーダ
１０３ 記憶部
１０４ 通信パケット処理部
１０５ データ送受信部
８５９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a data communication system, a data transmission device, a data reception device, a method, and a computer program. More specifically, a data communication system, a data transmission device, a data reception device, a method, and a computer capable of efficiently transmitting optimum encoded data according to a desired data processing mode of a data reception side・ Regarding the program.
[0002]
[Prior art]
Currently, various data transfers are performed via various communication media such as Internet communication. In recent years, transfer of image data, particularly moving image data, via a network has been actively performed. Image data, particularly moving image data, is reduced in data amount by encoding (compression) processing on the transmission side and is transmitted over a network, and the reception side is decoded (decompressed) on an encoded reception signal and then reproduced. Processing is generally performed.
[0003]
One of the most well-known methods of image compression processing is MPEG (Moving Pictures Experts Group) compression technology. In recent years, a system in which an MPEG stream generated by MPEG compression is stored in IP packets according to IP (Internet Protocol) and transferred over the Internet, and received by each communication terminal such as a PC, PDA, or mobile phone, or Technical developments relating to image data transfer methods in such systems have been actively conducted.
[0004]
2. Description of the Related Art In real-time communication such as video-on-demand or streaming distribution of live video, or video conference or videophone, it is necessary to assume that data transmission and reception are performed using terminals having different capabilities as receiving terminals. For example, transmission data from one information transmission source is received by a receiving terminal having a low-resolution display such as a mobile phone and a CPU having a low processing capability and is subjected to a process of displaying the data on a display. As described above, the display processing is executed by receiving the image by the receiving terminal having the high-resolution monitor and the CPU having the high processing ability. Thus, data transmission is performed with respect to various receiving terminals having different processing capabilities. As described above, as one method for executing reception processing and display processing in accordance with the processing capability and the like in various receiving terminals, a method of performing hierarchical coding of data to be transmitted and received, that is, using hierarchical coding Communication systems are being considered.
[0005]
Data distribution by hierarchical encoding is, for example, a process in which encoded data is processed only in a receiving terminal having a high-resolution display, and is commonly processed in both a receiving terminal having a high-resolution display and a receiving terminal having a low-resolution display. And coded data to be packetized in a distinguishable manner and distributed, so that the receiving side can select and process the data.
[0006]
As a compression / expansion method capable of hierarchical coding, for example, a video stream based on MPEG4 and JPEG2000 can be cited. In MPEG4, FineGranularity Scalability technology will be taken into the standard and profiled, and it is said that this hierarchical coding technology enables scalable distribution from a low bit rate to a high bit rate. In addition, JPEG2000 based on the wavelet (Wavelet) transform can make use of the features of the wavelet (Wavelet) transform to packetize based on spatial resolution or hierarchically based on image quality. is there. JPEG2000 can store hierarchical data in a file format according to the Motion JPEG2000 (Part 3) standard that can handle not only still images but also moving images.
[0007]
Further, as a specific proposal of data distribution to which hierarchical coding is applied, there is a proposal using a DCT (Discrete Cosine Transform) -based technique. This is done by, for example, performing DCT processing on image data serving as distribution information, realizing hierarchies in which high-frequency and low-frequency bands are distinguished by DCT processing, generating packets that are divided into high-frequency and low-frequency layers, and performing data distribution. Is a way to do that.
[0008]
In the case of distributing such hierarchically encoded image data, real-time processing is often required. Therefore, UDP (User Datagram Protocol) is used as a communication protocol on the Internet. Further, in a layer above UDP, RTP (Real-time Transport Protocol) is used, and a data format stored in a communication packet follows a format defined for each application, that is, for each encoding method.
[0009]
When data is transmitted from a server to various clients using a network environment such as the Internet, when available network bandwidths and data processing capabilities on the client side, that is, decoding (decoding) processing or display display capabilities are different. There is. That is, the bit rate of transmission data desired by each client is different. Therefore, the server on the data transmission side previously encodes data at a plurality of bit rates, saves the plurality of bit rate data, and transmits data selected from the saved data in response to a request from the client. .
[0010]
For example, if the available network bandwidth is wide, it is considered that the client requests high bit rate data, so the server transmits the high bit rate data from a plurality of data stored in advance. Conversely, if the available bandwidth is narrow, the client requests low bit rate data, and the server will transmit the data accordingly.
[0011]
For example, Patent Literature 1 discloses a conventional image data transmission processing configuration that considers the transmission data suitability of each client. Patent Literature 1 discloses a configuration in which an image transmission device detects a data transmission state and changes a compression processing mode of image data according to the transmission state. The data transmission device has transmission status information according to the data transmission destination, and in the case of data transmission to an area where the transmission status is poor, for example, transmits data subjected to compression processing in which the resolution has been reduced and the data amount has been reduced. . On the other hand, in the case of data transmission to an area where the transmission status is good, the resolution is improved, and data subjected to compression processing with a large data amount is transmitted. With this configuration, a configuration that enables data transmission according to the situation is disclosed.
[0012]
However, the configuration disclosed in Patent Document 1 requires that the data transmission device perform processing by dynamically changing the compression processing mode according to the data transmission situation. If it occurs frequently, it is necessary to change the compression processing mode for each request and execute it, which causes a problem that the processing load on the data transmission side becomes excessive.
[0013]
[Patent Document 1]
JP-A-14-262288
[0014]
[Problems to be solved by the invention]
SUMMARY OF THE INVENTION The present invention has been made in view of the above-described problems, and transmits optimal coded data according to various situations on the data receiving side and reduces a processing load on the data transmitting side, thereby achieving an efficient optimal coding. It is an object of the present invention to provide a data communication system, a data transmission device, a data reception device, a method, and a computer program which enable transmission processing of encrypted data.
[0015]
[Means for Solving the Problems]
According to a first aspect of the present invention,
A server that performs a process of transmitting hierarchically encoded data, and a server client system including a client that receives hierarchically encoded data from the server,
The client,
The data request message to be transmitted to the server has a configuration for executing a process of storing and transmitting request data mode identification information indicating the hierarchically encoded data mode requested by the client,
The server comprises:
A process of extracting or generating encoded data corresponding to the request data mode identification information from a storage unit based on the request data mode identification information included in the data request message received from the client, and transmitting the encoded data to the client In a server-client system.
[0016]
Further, in one embodiment of the server-client system of the present invention, the client may include the request data mode identification information in a description of a play [PLAY] method according to RTSP (Real-time Streaming Protocol) as a control information communication protocol. Is stored and transmitted to the server. The server acquires the request data mode identification information from the description of the play [PLAY] method received from the client, and acquires the acquired request data. It is characterized in that it is configured to execute a process of extracting or generating encoded data corresponding to the aspect identification information.
[0017]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information includes at least one of resolution information and image quality information. It is characterized by.
[0018]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information is a number of JPEG2000 encoded data packets (JP2 packets) per frame. There is a feature.
[0019]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information is an LRCP (Layer-resolution level) as a progression type in the JPEG2000 encoded data. -Component-position progress) or RLCP (Resolution level-layer-component-position progress) designation information.
[0020]
Further, in one embodiment of the server-client system of the present invention, the request data mode identification information includes an R value corresponding to a wavelet transform count value associated with a hierarchically encoded data generation process or an L value corresponding to the number of layers. It is characterized by including at least one piece of designated information.
[0021]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is MPEG format data, and the request data mode identification information is a division number of an enhancement layer in the MPEG encoded data. Features.
[0022]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is MPEG format data, and the request data mode identification information is an image quality that determines an information amount of an enhancement layer in the MPEG encoded data. It is characterized by a value of PSNR (Peak Signal to Noise Ratio) as an index value.
[0023]
Further, in one embodiment of the server client system of the present invention, the client executes a process of transmitting a data specification request to a server before transmitting the data request message, and the server executes a data specification request received from the client. Transmitting a response message storing the server-maintained data mode identification information to the client as a response to the client. The client acquires the server-maintained data mode identification information from the response message received from the server. And determining a layer encoded data mode requested by the client based on the obtained information, storing the determined information in the data request message as the requested data mode identification information, and transmitting the data to the server. It is characterized by having a configuration.
[0024]
Further, in one embodiment of the server-client system of the present invention, the client transmits a data specification request to the server by a describing [DESCRIBE] method according to RTSP (Real-time Streaming Protocol) as a control information communication protocol. The server transmits to the client a response message storing the server-maintained data mode identification information as a response to the describable [DESCRIBE] method received from the client, and the client receives the response received from the server. Obtain server retained data mode identification information from the message, determine the layer encoded data mode requested by the client based on the obtained information, and use the determined information as the requested data mode identification information. Wherein the stored in the description of the play [PLAY] Methods in accordance with the RTSP is configured to perform processing of transmitting to the server.
[0025]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information and the server retained data mode identification information are at least resolution information and image quality information. It is characterized by including any information.
[0026]
Further, in one embodiment of the server client system of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information and the server retained data mode identification information are a progression type in JPEG2000 encoded data. LRCP (Layer-resolution level-component-position progression) or RLCP (Resolution level-layer-component-position progression).
[0027]
Further, in one embodiment of the server-client system of the present invention, the request data mode identification information and the server-maintained data mode identification information each have an R value corresponding to a wavelet transform count value associated with hierarchically encoded data generation processing, or It is characterized by including at least one piece of designation information of an L value corresponding to the number of layers.
[0028]
Further, in one embodiment of the server client system of the present invention, the hierarchically coded data is MPEG format data, and the request data mode identification information and the server retained data mode identification information are enhancement data in MPEG encoded data. It is characterized by the number of layers divided.
[0029]
Further, in one embodiment of the server client system of the present invention, the hierarchically coded data is MPEG format data, and the request data mode identification information and the server retained data mode identification information are enhancement data in MPEG encoded data. It is a PSNR (Peak Signal to Noise Ratio) value as an image quality index value for determining the information amount of a layer.
[0030]
Further, a second aspect of the present invention provides
A data transmission device as a server that performs a transmission process of the hierarchically encoded data,
A communication unit for transmitting and receiving data to and from the client;
A control unit that extracts or generates encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message received from the client via the communication unit;
Having a communication packet processing unit that generates a communication packet storing the encoded data extracted or generated under the control of the control unit,
A data transmitting apparatus having a configuration for executing processing for transmitting to a client a communication packet storing encoded data corresponding to the client generated in the communication packet processing unit.
[0031]
Further, in one embodiment of the data transmission device of the present invention, the client may include the request data mode identification information in the description of a play [PLAY] method according to RTSP (Real-time Streaming Protocol) as a control information communication protocol. The control unit acquires the request data mode identification information from the description of a play [PLAY] method received from the client, and executes the acquired request. It is characterized in that it is configured to execute a process of extracting or generating encoded data corresponding to the data mode identification information.
[0032]
Further, in one embodiment of the data transmission device of the present invention, the data transmission device receives a data specification request from a client via the communication unit, and the control unit transmits the hierarchically encoded data stored in the storage unit. It is characterized in that it is configured to execute a process of transmitting to the client a response message storing the server-maintained data mode identification information as mode information.
[0033]
Further, in one embodiment of the data transmitting apparatus of the present invention, the hierarchically coded data is JPEG2000 format data, and the server retained data mode identification information includes at least one of resolution information and image quality information. It is characterized by the following.
[0034]
Further, in one embodiment of the data transmitting apparatus of the present invention, the hierarchically coded data is JPEG2000 format data, and the server retained data mode identification information is LRCP (Layer-resolution) as a progression type in the JPEG2000 coded data. Level-component-position progress (RL-CP) or RLCP (Resolution level-layer-component-position progress) specification information is included.
[0035]
Further, in one embodiment of the data transmitting apparatus of the present invention, the server-maintained data mode identification information includes an R value corresponding to a wavelet transform count value associated with a hierarchically encoded data generation process, or an L value corresponding to a layer number. Or at least any one of the specified information.
[0036]
Further, in one embodiment of the data transmitting apparatus of the present invention, the hierarchically coded data is MPEG format data, and the server retained data mode identification information is a division number of an enhancement layer in the MPEG coded data. It is characterized by.
[0037]
Further, in one embodiment of the data transmitting apparatus of the present invention, the hierarchically coded data is MPEG format data, and the request data mode identification information and the server-maintained data mode identification information are enhancement data in MPEG encoded data. It is a PSNR (Peak Signal to Noise Ratio) value as an image quality index value for determining the information amount of a layer.
[0038]
Further, a third aspect of the present invention provides
A data receiving device as a client that receives hierarchically encoded data from a server,
The data receiving device,
A communication unit for transmitting and receiving data to and from the server;
A control unit that performs a process of determining a hierarchically encoded data mode requested by itself, and sets the determination information as request data mode identification information to be stored in a data request message transmitted to the server via the communication unit,
A data receiving apparatus having a configuration for executing processing for storing and transmitting the request data mode identification information in a request message of hierarchically encoded data to a server.
[0039]
Further, in one embodiment of the data receiving apparatus according to the present invention, the data receiving apparatus includes the request data mode during the description of a play [PLAY] method according to an RTSP (Real-time Streaming Protocol) as a control information communication protocol. It is characterized by executing processing for storing identification information and transmitting it to the server.
[0040]
Further, in one embodiment of the data receiving device of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information includes at least one of resolution information and image quality information. It is characterized by.
[0041]
Further, in one embodiment of the data receiving apparatus of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information is the number of JPEG2000 encoded data packets (JP2 packets) per frame. There is a feature.
[0042]
Further, in one embodiment of the data receiving apparatus of the present invention, the hierarchically encoded data is JPEG2000 format data, and the request data mode identification information is an LRCP (Layer-resolution level) as a progression type in the JPEG2000 encoded data. -Component-position progress) or RLCP (Resolution level-layer-component-position progress) designation information.
[0043]
Further, in one embodiment of the data receiving apparatus of the present invention, the request data mode identification information includes an R value corresponding to the number of wavelet transform times associated with the generation processing of the hierarchically coded data, or an L value corresponding to the number of layers. It is characterized by including at least one piece of designated information.
[0044]
Further, in one embodiment of the data receiving apparatus of the present invention, it is preferable that the hierarchically coded data is MPEG format data, and the request data mode identification information is a division number of an enhancement layer in the MPEG coded data. Features.
[0045]
Further, in one embodiment of the data receiving apparatus of the present invention, the hierarchically encoded data is MPEG format data, and the request data mode identification information is an image quality that determines an information amount of an enhancement layer in the MPEG encoded data. It is characterized by a value of PSNR (Peak Signal to Noise Ratio) as an index value.
[0046]
Further, in one embodiment of the data receiving device of the present invention, the data receiving device executes a process of transmitting a data specification request to a server before transmitting the data request message, and performs a process of transmitting a data specification request from a response message received from the server. Obtain server retained data mode identification information, determine the hierarchically encoded data mode requested by itself based on the obtained information, store the determined information in the data request message as the requested data mode identification information, It is characterized in that it is configured to execute processing for transmitting to a server.
[0047]
Further, a fourth aspect of the present invention provides
A data transmission method for performing a transmission process of hierarchically encoded data,
Receiving a data request message from a client;
A control step of extracting or generating encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message;
A communication packet generating step of generating a communication packet storing the extracted or generated encoded data,
Transmitting a communication packet containing encoded data corresponding to the client to the client;
And a data transmission method characterized by having:
[0048]
Further, in one embodiment of the data transmission method of the present invention, the control step obtains the request data mode identification information from a description of a play [PLAY] method received from the client, and obtains the obtained request data mode identification. It is a step of executing a process of extracting or generating encoded data corresponding to the information.
[0049]
Further, in one embodiment of the data transmission method according to the present invention, the data transmission method further includes a step of receiving a data specification request from a client via the communication unit, and a mode of the hierarchically encoded data stored in the storage unit. Transmitting to the client a response message storing the server-maintained data mode identification information as information.
[0050]
Furthermore, a fifth aspect of the present invention provides
A data request processing method for performing a request processing of hierarchically encoded data to a server,
A request data mode determining step of executing a hierarchically encoded data mode determining process requested by itself,
Storing the request data mode determined in the determination step in the data request message to be transmitted to the server as request data mode identification information;
Sending the data request message to a server;
And a data request processing method characterized by having:
[0051]
Further, in one embodiment of the data request processing method of the present invention, the data request message is transmitted to the server as a play [PLAY] method according to a real-time streaming protocol (RTSP) as a control information communication protocol. It is characterized by the following.
[0052]
Further, a sixth aspect of the present invention provides
A computer program for performing a data transmission process of performing a transmission process of the hierarchical encoded data,
Receiving a data request message from a client;
A control step of extracting or generating encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message;
A communication packet generating step of generating a communication packet storing the extracted or generated encoded data,
Transmitting a communication packet containing encoded data corresponding to the client to the client;
A computer program characterized by comprising:
[0053]
Further, a seventh aspect of the present invention provides
A computer program for executing a data request process for executing a request process for hierarchically encoded data to a server,
A request data mode determining step of executing a hierarchically encoded data mode determining process requested by itself,
Storing the request data mode determined in the determination step in the data request message to be transmitted to the server as request data mode identification information;
Sending the data request message to a server;
A computer program characterized by comprising:
[0054]
[Action]
According to the configuration of the present invention, in a server client system including a server that executes transmission processing of hierarchically encoded data and a client that receives hierarchically encoded data from the server, a data request message transmitted from the client to the server is , Storing and transmitting request data mode identification information indicating the hierarchically encoded data mode requested by the client, and the server extracting or generating encoded data corresponding to the client based on the request data mode identification information and transmitting the data to the client. In this configuration, the optimal data transmission can be performed according to the processing capability of the client.
[0055]
Moreover, according to the configuration of the present invention, the server can extract data of various configurations from the only coded data stored in the storage unit as transmission data by extracting data in response to a request from the client. In addition, the server does not need to store a plurality of data of various types, thereby enabling efficient processing.
[0056]
Further, according to the configuration of the present invention, the client executes a process of transmitting a data specification request to the server before transmitting the data request message, and the server transmits a response message storing the server-maintained data mode identification information as a response to the client. And the client can determine the hierarchically encoded data mode requested by the client based on the server-held data mode identification information, and can request data within a range that the server reliably holds.
[0057]
The computer program of the present invention is provided, for example, in a computer-readable format for a general-purpose computer system capable of executing various program codes, in a storage medium or communication medium such as a CD, FD, or MO. Or a computer program that can be provided by a communication medium such as a network. By providing such a program in a computer-readable format, processing according to the program is realized on a computer system.
[0058]
Further objects, features and advantages of the present invention will become apparent from the following detailed description based on embodiments of the present invention and the accompanying drawings. In this specification, the term “system” refers to a logical set of a plurality of devices, and is not limited to a device having each component in the same housing.
[0059]
BEST MODE FOR CARRYING OUT THE INVENTION
[System Overview and Data Transmission / Reception Configuration Example]
First, a system outline and a data transmission / reception configuration example of the present invention will be described. FIG. 1 shows a configuration example of a data transmission / reception system to which the present invention can be applied. In the present invention, as shown in FIG. 1, an environment is assumed in which a server 11 as a data transmitting device and clients 21, 22, and 23 as data receiving devices are connected to a network 12, and data is transmitted and received via the network 12. Although three clients are shown in the figure, it is assumed that many clients are connected on the network.
[0060]
The server 11 stores the encoded data in a recording medium such as an HDD. It is assumed that an image compression method using hierarchical coding is used as the encoding method at this time. In the following description, a method for transmitting and receiving encoded data will be described as a specific example, but the present invention is also applicable to a configuration in which the server 11 executes real-time encoding. Each of the clients 21, 22, and 23 has a decoding environment corresponding to the encoding method used in the server, that is, a decoder, and has a display or a speaker as output means of decoded data.
[0061]
In this embodiment, an IP (Internet Protocol) connection network is assumed. Real-time performance is often required for distribution of image or audio data, and in many cases, UDP (User Datagram Protocol) is used as a communication protocol on the Internet. Furthermore, RTP (Real-time Transport Protocol) is used in a layer above UDP. While RTP is used as a transmission plane for content data, RTSP (Real-time Streaming Protocol) is used as a control information transmission plane.
[0062]
In the RTSP, a plurality of methods are defined as control functions. For example, a description is provided as a description [DESCRIBE] defined as a method for requesting content from a client to a server, and as a transmission start method for media (content). Various methods (control functions) such as [PLAY], [SETUP] defined as a resource request for media and an RTSP session start method, and [TEARDDOWN] defined as a session end method are applicable.
[0063]
The server 11 at the data transmission site holds hierarchically encoded data generated by wavelet transform or hierarchically encoding processing based on DCT or the like, and sends the hierarchically encoded data to the client from the hierarchically encoded data held in response to a data request from the client. The optimum data is extracted, and if necessary, rearrangement is performed as resetting of the encoded sequence, a communication packet storing the extracted data as a payload of the communication packet is generated, and transmitted to the data requesting client.
[0064]
The network 12 carries the communication packet to the destination based on the address information set in the communication packet. There are various data transmission modes. For example, a communication packet is transmitted to the client 21 via a service provider network that provides a dial-up service, or a packet is distributed to the client 22 via a service provider network using ADSL. You. Alternatively, a communication packet is delivered to the mobile client 23 via the base station 13 by a wireless network.
[0065]
Hereinafter, a plurality of processing examples of transmission / reception processing of encoded data to which the present invention is applied according to various data compression formats such as JPEG2000 and MPEG will be described.
[0066]
[Example 1]
First, as a first embodiment, an example in which JPEG2000 is applied to the hierarchical encoding method and RTSP is used as the transmission control method will be described.
[0067]
Hierarchical encoding processing such as JPEG2000 based on wavelet transform enables layer division setting with finely set layers or resolutions, and arbitrary bit rates corresponding to various data receiving terminals having different processing capabilities. It is possible to correspond to. Also, since a JPEG2000 video stream, which is a moving image compression format based on JPEG2000, is configured as a sequence of intra frames without inter-frame correlation, even if a packet loss occurs on a network, it is based on a lost packet. There is an advantage that error propagation does not occur for packets of Therefore, when the wavelet transform is applied, block noise does not occur, so that a decrease in visual image quality is suppressed.
[0068]
The embodiment described below is a system for transmitting and receiving hierarchically encoded data generated by hierarchical encoding processing to which a wavelet transform is applied. The server as a data transmitting device for transmitting data is adapted for optimal coded data according to the capability of a client as a data receiving device for receiving data, for example, a display resolution or a processing capability of a CPU (for example, a processable bit rate). Send
[0069]
In the system of the present invention, the configuration and processing of a server as a data transmission device that executes processing of generating and transmitting communication packets storing encoded data and storing the encoded data will be described. FIG. 2 is a block diagram illustrating a configuration example of the server.
[0070]
In the example illustrated in FIG. 2, the server 100 includes a control unit 101, an encoder (encoding unit) 102, a storage unit 103, a communication packet processing unit 104, and a data transmission / reception unit (network I / F) 105.
[0071]
The communication packet storing the encoded data is transmitted to the client as the data receiving device via the data transmitting / receiving unit 105. The encoded data to be transmitted is basically data stored in the storage unit 103. That is, a predetermined encoding process is executed by the encoder (encoding unit) 102 in advance, and from the encoded data stored in the storage unit 103, according to the encoded data mode desired by the client under the control of the control unit 101. The data extraction process is performed, a communication packet having the extracted encoded data as a payload is generated in the communication packet processing unit 104, and transmitted to the client as the data receiving device via the data transmitting / receiving unit 105. . In the data transmission process to the client, the encoder (encoding unit) 102 may execute the encoding process, and the encoded data may be stored in the communication packet in the communication packet processing unit 104 and transmitted to the client.
[0072]
Note that the configuration of the client side, that is, the optimal encoded data according to the CPU, decoder processing capacity, display configuration, or the like, or the optimal encoded data mode desired by the client, is determined before the server transmits the encoded data. The server acquires from the client by control information transmission processing executed between the servers, that is, information exchange by RTSP (Real-time Streaming Protocol). The control unit 101 executes encoded data extraction processing suitable for the client from the storage unit 103 based on the obtained information, and generates a communication packet based on the extracted data. Details of these processes will be described later.
[0073]
In the present embodiment, the storage unit 103 stores JPEG2000 encoded data based on the Wavelet transform. The encoder (encoding unit) 102 performs a JPEG2000 encoding process based on a wavelet (Wavelet) transform.
[0074]
FIG. 3 shows a configuration example of an encoder that performs a wavelet transform. This is an example in which octave division, which is the most general wavelet transform, among several wavelet transform methods is performed over a plurality of levels. In the case of FIG. 3, the number of levels is three (level 1 to level 3), and an image signal is divided into a low band and a high band, and only a low band component is hierarchically divided. FIG. 3 illustrates a wavelet transform for a one-dimensional signal (for example, a horizontal component of an image) for the sake of convenience. However, the wavelet transform can be extended to two-dimensional to correspond to a two-dimensional image signal.
[0075]
Next, the operation will be described. The input image signal 250 to the wavelet transform unit shown in FIG. 3 is first band-divided by the low-pass filter 211 (transfer function H0 (z)) and the high-pass filter 212 (transfer function H1 (z)), and the obtained low band The resolution of the component and the high-frequency component is thinned out by a factor of two by the corresponding downsamplers 213 and 214 (level 1). The outputs at this time are the L component 251 and the H component 256. Here, L indicates a low band (Low) and H indicates a high band (High). The low-pass filter 211, the high-pass filter 212, and the two down-samplers 213 and 214 in FIG.
[0076]
Only the low-frequency components of the signals decimated by the down samplers 213 and 214, that is, only the signal from the down sampler 213, are further band-divided by the low-pass filter and the high-pass filter of the level 2 circuit section 220, and the corresponding down Each sampler reduces the resolution by a factor of two (level 2). The circuit unit 220 including the level 2 low-pass filter, high-pass filter, and down-sampler has the same configuration as the circuit unit 210 including the level 1 low-pass filter 211, high-pass filter 212, and down-samplers 213 and 214. .
[0077]
By performing such processing up to a predetermined level, band components obtained by hierarchically dividing low-frequency components into bands are sequentially generated. The band components generated at level 2 are an LL component 252 and an LH component 255. FIG. 3 shows an example in which band division is performed up to level 3. The output from the down sampler on the low-pass filter side of the level 2 circuit section 220 is output to the level 3 circuit section 230 having the same configuration as the circuit section 210. Supplied. As a result of the band division to level 3, an LLL component 253, an LLH component 254, an LH component 255, and an H component 256 are generated.
[0078]
FIG. 4 illustrates band components obtained as a result of band division of a two-dimensional image up to level 3. The notation of L and H shown in FIG. 4 is different from the notation of L and H in FIG. 3 which deals with a one-dimensional signal. That is, in FIG. 4, first, four components LL, LH, HL, and HH are divided by level 1 band division (horizontal and vertical directions). Here, LL means that the horizontal and vertical components are both L, and LH means that the horizontal component is H and the vertical component is L. Next, the LL component is band-divided again to generate LLLL, LLHL, LLLH, and LLHH. Further, the LLLL component is band-divided again to generate LLLLLL, LLLLHL, LLLLLLH, and LLLLHH.
[0079]
In the wavelet transform process, a progressive encoding process in a progressive order can be executed. That is, it is possible to perform hierarchical coding according to various progressive modes, such as progressive by spatial resolution, or SNR (Signal to Noise Ratio), that is, progressive by image quality, or progressive by color components (RGB or YCbCr).
[0080]
Progression coding is a coding process that is frequently used in Internet image distribution and the like.At the data receiving terminal side, for example, coarse image data is output first, and fine images are sequentially output and displayed. This makes it possible to perform a typical decryption display process.
[0081]
For example, as an example of the progressive encoding, encoded data of high-frequency image data corresponding to a fine image is generated from encoded data of low-frequency image data corresponding to a coarse image. In a terminal that executes decoding and display of data, decoding and display processing of encoded data of low-frequency image data can be performed first, so that a rough schematic image can be displayed on a display in a short time, and thereafter, high-frequency By decoding and displaying the encoded data of the area, it is possible to gradually display a finer image.
[0082]
As the progressive coding, in addition to the step-by-step processing configuration of different resolutions, SNR (Signal to Noise Ratio), that is, a configuration in which image quality is set in a plurality of stages, is used to convert low SNR (low image quality) coded data to high SNR ( There is a configuration in which encoding is performed while distinguishing between high-quality images, and a configuration in which progression using color components (RGB and YCbCr), that is, encoding for each color component (RGB and YCbCr) is performed.
[0083]
The final processing in the encoder that performs data encoding by wavelet transform is processing of rearranging the generated encoded bit stream into a code sequence corresponding to a predetermined progression. JPEG2000 defines five types of progression types. Among them, there are LRCP (Layer-resolution level-component-position progression) and RLCP (Resolution level-layer-component-position-progression) as typical ones.
[0084]
The LRCP coded data sequence can be progressively decoded by sequentially decoding the coded data sequence to keep the resolution constant and gradually improve the image quality. On the other hand, RLCP enables progressive decoding in which the image quality is kept uniform and the resolution is gradually increased.
[0085]
The server as the data transmission device in the present embodiment holds the wavelet transform data in, for example, the above-described LRCP or RLCP code sequence. Information about whether the server holds LRCP or RLCP data, and encoding processing mode information about other encoded data, control information transmission processing executed between the server and client before transmission of the encoded data, That is, when information is exchanged by RTSP (Real-time Streaming Protocol), a process of notifying the client is performed. Details of these processes will be described later.
[0086]
The encoder 102 shown in FIG. 2 performs the above-described wavelet transform processing. The data encoded by the encoder 102 is stored in the storage unit 103. FIG. 5 shows the configuration of encoded data stored in the storage unit 103.
[0087]
The encoded data configuration shown in FIG. 5 will be described. The encoded data starts with an SOC (Start of Code stream) marker indicating the beginning of the encoded data, followed by a main header (MH: Main Header) in which encoding parameters, quantization parameters, a progressive order, and the like are described, and thereafter. Followed by encoded data. This encoded data has a hierarchical structure. An EOC (End of Code stream) marker indicating the end of the coded data is set at the end of the coded data.
[0088]
The communication packet processing unit 104 as a communication packet generation unit analyzes the encoded data in the storage unit 103, determines a delimiter according to the data content, and executes a communication packet generation process. The communication packet processing unit 104 refers to the main header of the encoded data stored in the storage unit 103, and acquires progressive order information of the encoded data, information on the number of layers, and information on color components. By reading this field information, it is analyzed what hierarchy is constituted. As described above, the hierarchical level configuration method includes progressive based on resolution, SNR (Signal to Noise Ratio), that is, progressive based on image quality, progressive based on color components (RGB and YCbCr), and the like.
[0089]
The communication packet processing unit 104 as a communication packet generation unit performs extraction processing of encoded data stored in the storage unit 103 and further performs processing such as a progressive order of the encoded data in accordance with a client configuration as a data transmission destination. After performing the rearrangement process and the like, a process of storing the communication packet is executed. Details of these processes will be described later. The generated communication packet is transmitted to the client via the data transmission / reception unit (network I / F) 105.
[0090]
Note that the client as the data receiving device is configured by a PC, a mobile terminal, or the like, and has a configuration in which the encoder 102 is replaced with a decoder in the configuration illustrated in FIG. A specific example of a hardware configuration of a server as a data transmitting device and a client as a data receiving device will be described later.
[0091]
Next, the details of the control information transmission process executed between the server and the client before the transmission of the encoded data, that is, the information exchange process by the RTSP (Real-time Streaming Protocol) will be described.
As described above, the server as the data transmitting device is configured to provide information on the optimal encoded data according to the configuration (processing capability) of the client as the data receiving device or the optimal encoded data desired by the client. And transmits the encoded data in an optimal mode according to the client based on the acquired information.
[0092]
The information acquisition process for this is a control information transmission process executed between the server and the client before the transmission of the encoded data, that is, an information exchange process by RTSP (Real-time Streaming Protocol). This information exchange process includes a process of providing encoded data mode information (server retained data mode identification information) held by the server from the server to the client, and a desired encoded data mode information (requested data mode identification information) from the client to the server. And transmission processing.
[0093]
The server stores the hierarchically encoded data according to JPEG2000 based on the wavelet transform in the storage unit 103 (see FIG. 2), and the stored encoded data has the configuration shown in FIG. It has a configuration in which coded data is arranged in accordance with a predetermined coded sequence, following a main header (MH: Main Header) in which coding parameters, quantization parameters, a progressive order, and the like are described.
[0094]
The wavelet transform coded data shown in FIG. 6 indicates a JP2 packet configuration per frame. The above-mentioned RLCP (Resolution Level-Layer-Component-Position Progression) coded sequence, which is a code that enables progressive decoding that sequentially improves the coded data sequence to maintain uniform image quality and gradually increase resolution. It is a data string. The RLCP coded data shown in FIG. 6 performs wavelet transform five times, converts each coefficient into a bit plane into four layers, compresses them with three components (YUV), and arranges JP2 packets according to the JPEG2000 data format in RL order. This is an encoding sequence setting.
[0095]
As shown in FIG. 6, RLCP coded data in which the wavelet transform is executed five times and each coefficient is bit-planed into four layers has a setting of R = 5 and L = 4 and is indicated as RL54. R (Resolution) corresponds to the number of wavelet transforms, and L corresponds to the number of layers. In the configuration shown in FIG. 6, the server has 24 encoded data storage JP2 packets ((R0, L0) to (R5, L3)) per frame for each component.
[0096]
The JP2 packet is different from a communication packet transmitted via a network. In this specification, the unit data of the JPEG2000 encoded data stored in the storage unit 103 (see FIG. 2) of the server is expressed as a JP2 packet, and a packet transmitted via a network is expressed as a communication packet.
[0097]
Note that performing the wavelet transform five times and converting each coefficient into a bit plane into four layers means that five resolution (R: Resolution) information blocks R0 to R5 are provided, and four layers (L: Layer) are provided for each resolution information block. ) Means to have an encoded data block. The resolution R5 corresponds to a resolution of 720 × 480 pixels, R4 corresponds to a resolution of 360 × 240 pixels, and R0 corresponds to the lowest resolution image information. The layer corresponds to coarse image data (low-frequency image data) to fine image data (high-frequency image data) in the same resolution data. Here, four layers are set for each resolution. Also, an RLCP coded sequence shown in FIG. 6 exists for each of the three components (YUV).
[0098]
For example, when the client receives the encoded data sequence shown in FIG. 6 from the server, by decoding the JP2 packet of (R0, L0), coarse image data (low-frequency image data) is displayed at the lowest resolution, and sequentially , (R0, L1) to (R5, L3), a high-resolution fine image data (high-frequency image data) is displayed.
[0099]
However, if the display of the client does not have a resolution of 720 × 480 pixels, the decoding process of the JP2 packet included in R5 will be useless. Further, even if a client having a display with low bit information that can be displayed per pixel acquires high-frequency image data of a high layer and performs a decoding process, it is not possible to display a high-definition image based on the decoded data on the display. And there is no meaning in the processing. Also, the encoded data that can be processed differs depending on the decoding processing configuration on the client side. Therefore, in order to extract and transmit an optimal coded data sequence suitable for the client configuration, an information exchange process between the server and the client by RTSP (Real-time Streaming Protocol) is executed.
[0100]
FIG. 7 shows a control sequence exchange process according to the RTSP (Real-time Streaming Protocol) executed between the server and the client, and a process sequence up to transmission of encoded data after the information exchange. Hereinafter, the details of the processing will be described according to the processing sequence shown in FIG.
[0101]
In step S11, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0102]
When the server receives the method [DESCRIBE] from the client, in step S12, the server executes a process of transmitting the specification information of the content, that is, the server retained data mode identification information to the client according to the SDP (Session Description Protocol). The description of the SDP includes the server holding data mode identification information. FIG. 8 shows a data format according to SDP notified from the server to the client.
[0103]
[V = 0] indicates that version information = 0. [O = -2890xxx42xx 28xxx42xx7 IN IP4 4x. x7.1xx. 7x] is the session ID, IP version 4, and IP address information. [S = RTSP session] indicates that the protocol is based on RTSP. [U = rtsp: /// vodserver / contents / videoA. [sdp] is information indicating the storage location of the SDP file corresponding to the content in the server. [T = 0 1234] indicates a start time = 0 and an end time 1234 according to NTP (Network Time Protocol). [M = video 0 RTP / AVP 78] is media information, and indicates that video information can be transmitted in accordance with RTP (Real-time Transport Protocol). [A = control: rtsp: /// vodserver / contents / videoA. [mj2] is information indicating the storage location of the JPEG200 encoded data content (VideoA) in the server. mj2 indicates that the data is JPEG2000 encoded data.
[0104]
In the configuration of the present invention, the SDP is extended to further define [a = order: RL54 720 × 480] as a new content attribute (Attribute) in each of the above-described information. This is the server retained data mode identification information. [A = order: RL54 720 × 480] is information indicating the mode of the encoded data of the content held by the server. That is, this is information indicating that the server holds the content requested by the client as RLCP encoded string data shown in FIG.
[0105]
order: RL54 executes wavelet transform five times, and sets the data obtained by converting each coefficient into a bit plane into four layers into an RLCP coded data sequence, that is, (R0, L0), (R0, L1), to (R5). , L4) have encoded data. 720 × 480 indicates resolution information.
[0106]
Returning to FIG. 7, the description of the processing sequence between the server and the client will be continued. In step S12, the client acquires the content specification information from the server, that is, the server retained data mode identification information by SDP. As described above, the SDP can acquire resolution and image quality information as encoded data information, specifically, encoded data string information (RL54) and resolution information (720 × 480).
[0107]
The client sets the request data mode identification information corresponding to the encoded image data desired by the client based on the encoded data information of the server included in the received SDP. That is, in the present embodiment, the number of JP2 packets per frame that the client wants to receive is calculated, and in step S13, [the number of JP2 packets / 1 frame] as the calculated value is stored as the request data mode identification information. A playback request method [PLAY] is transmitted to the server.
[0108]
The processing from the reception of the SDP by the client to the transmission of the PLAY method will be described with reference to the flow shown in FIG. Upon receiving the SDP from the server in step S101, the client acquires resolution information (here, A) and each value of RL information from the SDP in step S102.
[0109]
Next, in step S103, a required resolution B (X × Y) determined based on information of the display or the like of the client is acquired, and in step S104, the resolution A of the encoded data held by the server acquired from the SDP is obtained. The client requested resolution B is compared.
[0110]
If A ≦ B, an image of resolution A (for example, 720 × 480) can be displayed on the display of the client, and the encoded data held by the server can be decoded and displayed on the client. Therefore, the process proceeds to step S106. . On the other hand, if A> B, an image with the resolution A (for example, 720 × 480) cannot be displayed on the display of the client, and therefore, in step S105, an update process for setting the resolution A to A / 2 is executed. The updating process for setting the resolution A to A / 2 corresponds to the updating process for setting R = R-1. This updating process is executed until the determination condition A> B in step S104 is determined to be No.
[0111]
If the determination of A> B is No, in step S106, the number of JP2 packets per frame that the client wants to receive is calculated. [JP2 packet number / 1 frame] will be referred to as [X-Priority]. The formula for calculating [X-Priority] is as shown in the following formula (Formula 1).
X-Priority = (number of wavelets + 1) × number of layers (formula 1)
[0112]
That is, assuming that the number of wavelets is 3 and the layer is 4, the value of X-Priority is 16. This value of X-Priority is a value corresponding to the number of JP2 packets per frame corresponding to the resolution requested by the client.
[0113]
In step S107, the client stores the calculated value of the X-Priority as an additional header in the play [PLAY] method of the RTSP, and transmits the value to the server. FIG. 10A shows the data configuration of the play [PLAY] method of RTSP transmitted from the client to the server.
[0114]
[PLAY rtsp: /// server / contents / videoA. [mj2 RTSP / 1.0] is a request to reproduce video information (VideoA), which is requested content, that is, information indicating a play method. [Cseq: 4] is a communication sequence number. [Session: 12345678] indicates a session number. [X-Priority: 16] is a newly defined header in the configuration of the present invention, and is a value indicating [JP2 packet number / 1 frame] requested by the client, calculated by the above equation (Equation 1), and is 16 Is shown.
[0115]
FIG. 10B shows acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client. [RTSP / 1.0 200 OK] indicates reception confirmation. [Cseq: 4] is a communication sequence number. [Session: 12345678] indicates a session number.
[0116]
In the sequence diagram shown in FIG. 7, in the ACK transmission in step S14, the ACK data shown in FIG. 10B is transmitted to the client, and then, in step S15, the stream distribution of the encoded data is executed to the client. You.
[0117]
The server extracts a JP2 packet from the encoded data held by the server according to [X-Priority] stored in the PLAY method received from the client, ie, [the number of JP2 packets / 1 frame] requested by the client, and performs communication. It is stored in a packet (RTP) and transmitted to the client.
[0118]
The server receives the PLAY method from the client, acquires the [JP2 packet number / 1 frame] requested by the client stored in the PLAY method, that is, the value of [X-Priority], and codes the server possesses according to the acquired value. The process from extracting the JP2 packet from the encrypted data to storing it in the communication packet (RTP) and transmitting it to the client will be described in detail with reference to FIG.
[0119]
First, in step S201, when the server receives a PLAY method which is a content reproduction request method from the client, the value of [X-Priority] from the received PLAY method in step S202, that is, [the number of JP2 packets / 1 required by the client] Frame] value.
[0120]
Next, in step S203, the server sequentially extracts encoded data corresponding to the designated content from the storage unit from the head data. The encoded data stored in the storage unit is the RLCP encoded data sequence described with reference to FIG. 6 and is the RL54 encoded data of R = 5, L = 4.
[0121]
The server counts the number of JP2 packets storing the encoded data obtained from the storage unit, and compares the counted number with the value of [X-Priority] obtained from the PLAY method received from the client in step S204. When the number of encoded data storage JP2 packets extracted from the storage unit becomes equal to the value of [X-Priority], the process proceeds to step S205, where a communication packet having the extracted JP2 packet as a payload, that is, an RTP packet is generated, and generated in step S206. And transmits the communication packet to the client.
[0122]
For example, if the value of [X-Priority] obtained from the PLAY method received from the client is 16, that is, the number of JP2 packets / 1 frame requested by the client is 16, the server sends 16 per frame. JP2 packet is extracted and transmitted to the client.
[0123]
In the above description, the number of JP2 packets storing the encoded data obtained from the storage unit is counted, and the value of [X-Priority] obtained from the PLAY method received from the client and the number of obtained JP2 packets are compared. Although the process is executed, a sequential number is set in advance from the beginning in the encoded data JP2 packet held by the server, and the setting number is compared with the value of [X-Priority], and the setting number ≦ X− It is also possible to perform a process of selecting only JP2 packets having a Priority value as transmission targets.
[0124]
The structure of the JP2 packet extracted by the server from the storage unit and stored in the communication packet is as shown in FIG. The example shown in FIG. 12 is an example where the value of [X-Priority] acquired from the PLAY method received from the client is 16, that is, the [JP2 packet number / 1 frame] requested by the client is 16.
[0125]
The block of R0 includes four JP2 packets of (R0, L0) to (R0, L3), and a total of 16 JP2 packets of (R0, L0) to (R3, L3) are extracted from the storage unit of the server. Then, it is stored and transmitted as a payload of a communication packet to the client. As described with reference to FIG. 6, the server holds the encoded data of the RL 54, that is, the encoded data composed of 24 JP2 packets per frame, but the server holds (R4, L0) to (R5, L3). ) Will not be transmitted.
[0126]
The client that has received the encoded data shown in FIG. 12 sequentially decodes and reproduces the JP2 packets (R0, L0) to (R3, L3), thereby executing a progressive reproduction process for sequentially improving the resolution and image quality. Thus, it is possible to reproduce an image according to the resolution requested by the client.
[0127]
[Example 2]
In the first embodiment described above, the request data mode identification information indicating the request coded data mode set during the play [PLAY] method transmitted from the client to the server is defined by the above-described equation (Equation 1). [X-Priority], that is, the calculated value of [the number of JP2 packets / 1 frame] requested by the client is set. Next, as a second embodiment, an RL value of encoded data requested on the client side during a play [PLAY] method transmitted from the client to the server, that is, a layer (L: Resolution) corresponding to the resolution (R: Resolution) and image quality A description will be given of a processing example in which the value of “Layer) is stored, and the JP2 packet to be transmitted is selectively extracted based on the RL value in the play [PLAY] method received by the server from the client.
[0128]
FIG. 13 shows a control information exchange process according to RTSP (Real-time Streaming Protocol) executed between server clients corresponding to the second embodiment, and a process sequence diagram up to transmission of encoded data after information exchange. . Hereinafter, the details of the processing will be described according to the processing sequence shown in FIG.
[0129]
The server stores hierarchically encoded data according to JPEG2000 based on the wavelet transform in the storage unit 103 (see FIG. 2), and the stored encoded data has the configuration shown in FIG. There is. That is, it is an RLCP (Resolution Level-Layer-Component-Position Progression) coded sequence, which is an RL54 in which wavelet transform is executed five times and each coefficient is bit-planed into four layers.
[0130]
In step S21 of the processing sequence of FIG. 13, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0131]
When the server receives the method [DESCRIBE] from the client, in step S22, the server executes a process of transmitting the specification information of the content, that is, the server-maintained data mode identification information to the client according to the SDP (Session Description Protocol). The data format according to the SDP notified from the server to the client has the same data as that of the first embodiment, that is, the data configuration shown in FIG. That is, it is data in which [a = order: RL54 720 × 480] is defined as a new content attribute (Attribute), and information indicating that a coded data sequence: RL54 and resolution: 720 × 480 code or data is held. Is presented to the client.
[0132]
In step S22, when the client obtains the server-maintained data mode identification information from the server by SDP, the client next determines RL information as encoded data information that the client wants to receive as request data mode identification information. Transmits a playback request method [PLAY] storing the RL value of the encoded data desired to be received by the client to the server.
[0133]
FIG. 14A shows the data configuration of the RTSP play [PLAY] method transmitted from the client to the server. [RL: 33] described in the bottom row of FIG. 14A is a newly defined header in this embodiment, and indicates that the RL value of the encoded data that the client wants to receive is RL33. Is shown. FIG. 14B shows acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client.
[0134]
In the sequence diagram shown in FIG. 13, in the ACK transmission in step S24, the ACK data shown in FIG. 14B is transmitted to the client, and then, in step S25, the stream distribution of the encoded data is executed to the client. You.
[0135]
The server extracts a JP2 packet from the encoded data held by the server according to the RL value stored in the PLAY method received from the client, that is, the RL value of the encoded data requested by the client, and converts the extracted JP2 packet into a communication packet (RTP). Store and send to client.
[0136]
The server receives the PLAY method from the client, acquires the RL value of the encoded data requested by the client stored in the PLAY method, extracts the JP2 packet from the encoded data held by the server according to the acquired value, and transmits the communication packet. The details of the processing from storing in (RTP) to transmission to the client will be described with reference to FIG.
[0137]
First, in step S301, when the server receives a PLAY method as a content reproduction request method from the client, in step S302, the server acquires the RL value of the encoded data requested by the client from the received PLAY method.
[0138]
Next, in step S303, the server performs initial setting of parameters for k = 0 and i = 1 as a pre-process for acquiring encoded data from the storage unit. k is a parameter indicating the number of the R block of the RL encoded data acquired from the storage unit. For R0, k = 0, and for R1, k = 1. i is a parameter indicating the number of the JP2 packet of each R block, i = 1 for L0 and i = 2 for L1.
[0139]
When the parameter initial setting in step S303 is completed, the process proceeds to step S304, and the server sequentially extracts encoded data corresponding to the designated content from the storage unit according to the set parameters k and i. The encoded data stored in the storage unit is the RLCP encoded data sequence described with reference to FIG. 6 and is the RL54 encoded data of R = 5, L = 4. Since the initial settings are k = 0 and i = 1, the L2 JP2 packet is extracted from the R0 block of the encoded data sequence shown in FIG.
[0140]
In step S305, the determination of [i ≧ the acquired value L from the PLAY method] is performed. Here, it is assumed that [RL: 33] described in the bottom row of FIG. 14A is set in the play [PLAY] method of the RTSP transmitted from the client to the server. That is, it is assumed that R = 3 and L = 3.
[0141]
Since the initial setting value i = 1 does not satisfy i ≧ 3, the process proceeds to step S311 to execute parameter update of i = i + 1, and proceeds to step S304 to acquire the next JP2 packet. That is, the L2 JP2 packet of the R0 block shown in FIG. 6 is obtained. JP2 packets in the same R block are acquired until i ≧ 3, and when i ≧ 3, determination of [k ≧ acquired value R from PLAY method] is performed in step S306. Since L = 3 due to the setting [RL: 33] of the PLAY method, the determination in step S306 is No at the initial setting k = 0, the process proceeds to step S312, and the parameter update to k = k + 1, i = 1 is performed. Be executed.
[0142]
By this update, the parameters become k = 1 and i = 1, and a JP2 packet corresponding to L0 of the R1 block of the encoded data string shown in FIG. 6 is obtained. By sequentially executing this processing, when the client designation is RL33, three JP2 packets L0 to L2 are obtained from the blocks R0 to R3 as shown in FIG.
[0143]
When the determinations in steps S305 and S306 are both Yes, and the JP2 packet extraction processing is completed, the flow advances to step S307 to generate a communication packet having the extracted JP2 packet as a payload, that is, an RTP packet. Send to
[0144]
The configuration of the JP2 packet extracted by the server from the storage unit and stored in the communication packet is as shown in FIG. The example shown in FIG. 16 is an example when the RL value acquired from the PLAY method received from the client is RL33.
[0145]
The block R0 includes three JP2 packets (R0, L0) to (R0, L2), and a total of 12 JP2 packets (R0, L0) to (R3, L2) are extracted from the storage unit of the server. Then, it is stored and transmitted as a payload of a communication packet to the client. As described with reference to FIG. 6, the server holds the encoded data of the RL 54, that is, the encoded data composed of 24 JP2 packets per frame, and the server holds (R0, L3), (R1, L3). ), (R2, L3), (R3, L3), and (R4, L0) to (R5, L3) JP2 packets will not be transmitted.
[0146]
The client receiving the encoded data shown in FIG. 16 sequentially decodes and reproduces the (R0, L0) to (R3, L2) JP2 packets, thereby executing a progressive reproduction process for sequentially improving the resolution and image quality. Thus, it is possible to reproduce an image according to the resolution requested by the client.
[0147]
[Example 3]
The first and second embodiments described above are examples in which the encoded data sequence held by the server is RLCP (Resolution level-layer-component-position progression), and the data sequence received by the client is also RLCP encoded data. Indicated. However, if the decoding processing function on the client side corresponds to the LRCP (Layer-resolution level-component-position progression), when the RLCP data is received, processing such as changing the data arrangement on the client side is required. It becomes.
[0148]
The processing load on the client side is reduced by changing the received data from the server side to LRCP so that the data is transmitted. In the third embodiment, a description will be given of a processing example in which RL or LR is specified in a PLAY method transmitted from the client side to the server, and the server changes the array of the encoded data held by the server and transmits the encoded data. As described above, the LRCP coded data sequence can be progressively decoded by sequentially decoding the coded data sequence to keep the resolution constant and gradually improve the image quality. On the other hand, RLCP enables progressive decoding in which the image quality is kept uniform and the resolution is gradually increased.
[0149]
FIG. 17 shows a control sequence exchange process in accordance with RTSP (Real-time Streaming Protocol) executed between server clients corresponding to the third embodiment and a process sequence up to transmission of encoded data after information exchange. . Hereinafter, the details of the processing of the third embodiment will be described according to the processing sequence illustrated in FIG.
[0150]
The server stores hierarchically encoded data according to JPEG2000 based on the wavelet transform in the storage unit 103 (see FIG. 2), and the stored encoded data is shown in FIG. 6 as in the first and second embodiments. It is assumed to be a configuration. That is, it is an RLCP (Resolution Level-Layer-Component-Position Progression) coded sequence, which is an RL54 in which wavelet transform is executed five times and each coefficient is bit-planed into four layers.
[0151]
In step S31 of the processing sequence of FIG. 17, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0152]
When the server receives the method [DESCRIBE] from the client, in step S32, the server executes a process of transmitting the specification information of the content, that is, the server retained data mode identification information to the client according to the SDP (Session Description Protocol). The data format according to the SDP notified from the server to the client has the same data as in the first and second embodiments, that is, the data configuration shown in FIG. That is, this is data in which [a = order: RL54 720 × 480] is defined as a new content attribute (Attribute), and information indicating that encoded data string: RL54 and resolution: 720 × 480 encoded data are held. Is presented to the client.
[0153]
In step S32, when the client obtains the content specification information from the server, that is, the server retained data mode identification information by SDP, the client determines the encoded data information that the client wants to receive. In step S23, the client determines the code data that the client wants to receive. The playback request method [PLAY] storing the encrypted data information, ie, the requested data mode identification information, is transmitted to the server.
[0154]
The processing from the reception of the SDP to the transmission of the PLAY method in the client will be described with reference to the flow shown in FIG. Upon receiving the SDP from the server in step S321, the client acquires the resolution information (here, A) and the values of the RL information (RL54) from the SDP in step S322.
[0155]
Next, in step S323, the required resolution B (X × Y) and RL or LR code determined on the basis of the device configuration of the client, such as CPU processing capacity, memory, bandwidth used, decoding specifications, display specifications, and the like. Determine the x and y of either the RLxy or the LRxy.
[0156]
Next, in step S324, the resolution A of the encoded data held by the server acquired from the SDP and the client requested resolution B are compared. If A ≦ B, an image of resolution A (for example, 720 × 480) can be displayed on the display of the client, and the encoded data held by the server can be decoded and displayed on the client. Therefore, the process proceeds to step S326. . On the other hand, if A> B, an image having the resolution A (for example, 720 × 480) cannot be displayed on the display of the client. Therefore, in step S325, an update process for setting the resolution A to A / 2 is executed. The updating process for setting the resolution A to A / 2 corresponds to the updating process for setting R = R-1. This updating process is executed until the determination condition A> B of step S324 is determined to be No.
[0157]
If the determination of A> B is No, in step S326, the set value of RLxy or LRxy as the transmission request encoded data (for example, LR34) is determined. Next, in step S327, the client stores the value of the determined LR34 as an additional header in the play [PLAY] method of the RTSP, and transmits it to the server. FIG. 19A shows the data configuration of the RTSP play [PLAY] method transmitted from the client to the server.
[0158]
[LR: 34] described in the bottom row of FIG. 19A is a newly defined header in the present embodiment, the encoded data that the client wants to receive is LRCP encoded data, and L = 3, LR34 of R = 4. FIG. 19B shows acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client.
[0159]
In the sequence diagram shown in FIG. 17, in the ACK transmission in step S34, the ACK data shown in FIG. 19B is transmitted to the client, and then, in step S35, the stream distribution of the encoded data LR34 is executed to the client. Is done.
[0160]
The server extracts the JP2 packet from the encoded data held by the server according to the request encoded data information stored in the PLAY method received from the client, that is, LR34, stores the JP2 packet in a communication packet (RTP), and transmits the packet to the client. .
[0161]
The server receives the PLAY method from the client, obtains LR34 as encoded data information requested by the client stored in the PLAY method, extracts a JP2 packet from the encoded data held by the server according to the acquired value, and performs communication. The details of the processing from storage in a packet (RTP) to transmission to the client will be described with reference to FIG.
[0162]
First, in step S341, when the server receives a PLAY method as a content reproduction request method from the client, in step S342, the server acquires encoded data information: LR34 requested by the client from the received PLAY method.
[0163]
Next, in step S343, the server performs initial setting of parameters for i = 0 and k = 1 as a pre-process for acquiring encoded data from the storage unit. i is a parameter indicating the order of the R block of the RL encoded data acquired from the storage unit. For R0, i = 0, and for R1, i = 1. k is a parameter indicating the number of the JP2 packet of each R block. If L0, k = 1, and if L1, k = 2.
[0164]
When the parameter initialization in step S343 is completed, the process proceeds to step S344, and the server sequentially extracts encoded data corresponding to the designated content from the storage unit according to the set parameters i and k. The encoded data stored in the storage unit is the RLCP encoded data sequence described with reference to FIG. 6 and is the RL54 encoded data of R = 5, L = 4. Since the initial settings are i = 0 and k = 1, the L0 JP2 packet is extracted from the R0 block of the encoded data string shown in FIG.
[0165]
In step S345, the determination of [i ≧ the obtained value R from the PLAY method] is performed. Here, it is assumed that [LR: 34] described in the bottom row of FIG. 19A is set in the play [PLAY] method of the RTSP transmitted from the client to the server. That is, L = 3 and R = 4.
[0166]
Since the initial setting value i = 0 does not satisfy i ≧ 4, the process proceeds to step S351, where the parameter update of i = i + 1 is executed, and the process proceeds to step S344 to acquire the next JP2 packet. That is, the JP2 packet of L0 in the R1 block shown in FIG. 6 is obtained. Thus, the first JP2 packet (L0) of each R block is obtained first. FIG. 21 shows the correspondence between (a) server holding data and (b) transmission data.
[0167]
The acquisition of the top JP2 packet in each R block is executed until i ≧ 4. If i ≧ 4, then in step S346, the determination of [k ≧ the acquired value L from the PLAY method] is performed. Since L = 3 due to the setting [LR: 34] of the PLAY method, in the case of the initial setting k = 1, the determination in step S346 is No, the process proceeds to step S352, and the parameter update to k = k + 1, i = 0 is performed. Be executed.
[0168]
By this update, the parameters become k = 2 and i = 0, and a JP2 packet corresponding to L1 of the R0 block of the encoded data string shown in FIG. 6 is obtained. By sequentially executing this processing, when the client designation is LR34, the LRCP encoded data array of LR34 is set as shown in FIG.
[0169]
If the determinations in steps S345 and S346 are both Yes, and the JP2 packet extraction processing is completed, the flow advances to step S347 to generate a communication packet having the JP2 packet composed of the extracted LR34 encoded data as a payload, that is, an RTP packet. Is transmitted to the client.
[0170]
The configuration of the JP2 packet stored in the communication packet is as shown in FIG. The example shown in FIG. 21 is an example where the request encoded data information acquired from the PLAY method received from the client is LR34.
[0171]
The transmission data has an LRCP configuration in which R0 to R4 are sequentially arranged in an L0 block, and R0 to R4 are sequentially arranged in an L1 block, and is an encoded data arrangement according to a request LR34 on the client side. It becomes.
[0172]
The client that receives the encoded data shown in FIG. 21 sequentially decodes and reproduces the (L0, R0) to (L2, R4) JP2 packets, thereby executing a progressive reproduction process for sequentially improving the resolution and image quality. Thus, the image can be reproduced according to the client's request.
[0173]
[Example 4]
In all of the first to third embodiments, the client transmits the RTSP method [DESCRIBE] as a content specification request to the server, and the client receives an SDP as a response from the server, and makes a request based on the SDP. A description has been given of a processing configuration example in which encoded information to be stored is stored in the PLAY method and transmitted to the server. Fourth Embodiment In a fourth embodiment, a description will be given of a processing example in a case where the client has the encoded information of the content held in the server in advance. That is, this is a processing mode in which the PLAY method is directly executed without using the RTSP method [DESCRIBE] and the SDP as a response, thereby receiving encoded information requested by the client from the server.
[0174]
FIG. 22 shows a communication processing sequence diagram executed between server clients corresponding to the fourth embodiment. Hereinafter, the details of the processing of the fourth embodiment will be described according to the processing sequence illustrated in FIG.
[0175]
In step S41 of the processing sequence in FIG. 22, the client transmits to the server the playback request method [PLAY] storing the encoded data information desired by the client, that is, the requested data mode identification information.
[0176]
The encoded data information stored in the playback request method [PLAY] by the client is determined based on the content data information of the server previously held by the client and information on the configuration (display, CPU, decoder specifications, etc.) of the client. The information includes, for example, information on the number of JP2 packets per frame described in the first to third embodiments, resolution information, or RLxy or LRxy setting information.
[0177]
The server that has received the playback request method [PLAY] storing the request encoded data information from the client executes ACK transmission in step S42, and subsequently in step S43, the request code stored in the playback request method [PLAY]. The stream distribution of the encoded data composed of the JP2 packet sequence extracted and generated according to the encoded data information is executed to the client.
[0178]
According to this method, since the PLAY method is directly executed without applying the RTSP method [DESCRIBE] and the SDP as a response, efficient processing is possible.
[0179]
[Example 5]
Although the above-described embodiment has been described as an example of the distribution processing of the encoded data according to the JPEG2000 data format, the present invention is not limited to the distribution configuration of the encoded data according to the JPEG2000 data format. Applicable in distribution processing. In the fifth embodiment, a description will be given of an example of a process of distributing encoded data having a format different from the JPEG200 data format, which is encoded data obtained by the wavelet transform process.
[0180]
FIG. 23 shows a control sequence exchange process according to RTSP (Real-time Streaming Protocol) executed between the server and the client and a process sequence up to transmission of encoded data after the information exchange. Hereinafter, the details of the processing will be described according to the processing sequence shown in FIG.
[0181]
In step S51, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0182]
Upon receiving the method [DESCRIBE] from the client, the server performs processing of transmitting the specification information of the content, that is, the server retained data mode identification information to the client in accordance with SDP (Session Description Protocol) in step S52. FIG. 24 shows a data format according to SDP notified from the server to the client.
[0183]
The data configuration from v to m in FIG. 24 is the same as the data described in the first embodiment with reference to FIG. [A = control: rtsp: /// vodserver / contents / videoA. [xxx]] is information indicating the storage location of the content (videoA) in the server. This content is encoded data in a format different from JPEG2000 encoded data.
[0184]
In the configuration of this embodiment, the SDP is extended, and [a = R5 720 × 480] is further defined as a new content attribute (Attribute) in each of the above-described information. [A = R5 720 × 480] is information indicating the mode of the encoded data of the content held by the server. R5 indicates encoded data obtained by performing the wavelet transform five times, and 720 × 480 indicates resolution information.
[0185]
Returning to FIG. 23, the description of the processing sequence between the server and the client will be continued. In step S52, the client acquires the content specification information from the server, that is, the server retained data mode identification information by SDP. The client can acquire R5 and 720 × 480 from the SDP as encoded data information.
[0186]
The client determines the requested encoded data information corresponding to the encoded image data desired by the client based on the encoded data information of the server included in the received SDP. For example, when requesting encoded data having a resolution corresponding to R3, a reproduction request method [PLAY] in which the requested encoded data information: R3 is set is transmitted to the server.
[0187]
The processing from the reception of the SDP to the transmission of the PLAY method in the client will be described with reference to the flow shown in FIG. Upon receiving the SDP from the server in step S501, the client acquires resolution information (here, A) and an R information value from the SDP in step S502.
[0188]
Next, in step S503, a required resolution B (X × Y) determined based on information of the display or the like of the client is acquired, and in step S504, the resolution A of the encoded data held by the server acquired from the SDP is obtained. The client requested resolution B is compared.
[0189]
If A ≦ B, an image of resolution A (for example, 720 × 480) can be displayed on the display of the client, and the encoded data held by the server can be decoded and displayed on the client. Therefore, the process proceeds to step S506. . On the other hand, if A> B, an image having a resolution A (for example, 720 × 480) cannot be displayed on the display of the client, and therefore, in step S505, an update process for setting the resolution A to A / 2 is executed. The updating process for setting the resolution A to A / 2 corresponds to the updating process for setting R = R-1. This updating process is performed until the determination condition A> B of step S504 is determined to be No.
[0190]
If the determination of A> B is No, in step S506, the requested encoded data information corresponding to the encoded data mode that the client wants to receive is determined.
[0191]
In step S507, the client stores the determined request encoded data information in the play [PLAY] method as an additional header and transmits the information to the server. FIG. 26A shows the data configuration of the RTSP play [PLAY] method transmitted from the client to the server.
[0192]
[PLAY rtsp: /// server / contents / videoA. xxx RTSP / 1.0] is a request to reproduce video information (VideoA) as requested content, that is, information indicating that the content is a play method. videoA. xxx is videoA. Unlike mj2, it indicates that the data is not JPEG2000 encoded data. Other information is the same as in the first embodiment, and a description thereof will not be repeated.
[0193]
[R: 3] described in the bottom row of FIG. 26A is a newly defined header in this embodiment, and the encoded data that the client wants to receive corresponds to R: 3 as the resolution. This indicates that the data is coded data. FIG. 26B shows reception acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client.
[0194]
In the sequence diagram shown in FIG. 23, in the ACK transmission of step S54, the ACK data shown in FIG. 26B is transmitted to the client, and subsequently, in step S55, the coded data requested by the client, that is, R3 The encoded data is extracted, and stream distribution using the generated RTP packet is executed for the client. The encoded data extraction processing is executed as the same processing as the processing described in each of the above embodiments. The server transmits the frame to the resolution required by the user in order from the low frequency component of the wavelet for each frame. The client receiving the encoded data decodes and reproduces the received data.
[0195]
As described in the present embodiment, even in a data format different from JPEG2000, the server can generate and adjust encoded data according to a request from the client to generate and transmit an encoded data sequence corresponding to the client. .
[0196]
[Example 6]
As described above, examples of the compression / expansion method capable of performing the hierarchical encoding include a video stream based on MPEG4 and JPEG2000. MPEG4 plans to incorporate FGS (Fine Granular Scalability) technology into a standard and profile it. It is said that this hierarchical encoding technology enables scalable distribution from a low bit rate to a high bit rate. In a sixth embodiment, a processing example using hierarchically encoded data according to MPEG4 will be described.
[0197]
A hierarchical coding method using FGS (Fine Granular Scalability) in MPEG4 is a compression method suitable for a streaming application, and is applicable to a moving image compression method based on DCT. The hierarchical encoding processing using FGS will be described with reference to FIG.
[0198]
As shown in FIG. 27, hierarchically encoded data using FGS (Fine Granular Scalability) in MPEG4 is composed of two layers: a base layer (Base Layer) and an enhancement layer (Enhancement Layer). The base layer (Base Layer) is compressed data generated based on a conventional discrete cosine transform and predictive coding. It is composed of three types of IPB picture information of an I picture having base information of inter-frame prediction processing, a P picture generated by forward prediction, and a B picture inserted between P pictures.
[0199]
The enhancement layer (Enhancement Layer) is encoded using an embedded DCT compression method or the like based on the base layer (Base Layer) and the original image. Although the minimum image quality can be obtained only with the base layer, a higher quality image can be obtained by adjusting the enhancement layer. Note that the image quality of a moving image is determined by the coding parameters of the enhancement layer and the amount of addition of the enhancement layer at the time of decoding.
[0200]
The information included in the enhancement layer (Enhancement Layer) of the FGS can be divided into an arbitrary number. For example, as shown in FIG. 28, it is possible to divide the enhancement layer into a plurality of parts and perform decoding processing using information of only the base layer and the layers selected from layers 1 to 5 included in the enhancement layer from the server to the client. It is possible.
[0201]
For example, the base layer and the layers 1 to 3 or 1 to 5 included in the enhancement layer are selected in response to a request from the client, transmitted to the client, and decoded on the client side in accordance with the reception layer. Is possible. Image data reproduction with the minimum image quality is possible only with the base layer, and the enhancement layer 1 alone performs a decoding process by applying a somewhat high-quality image and more enhancement layer information to perform the decoding process. High-quality image data can be displayed.
[0202]
As described above, the server extracts and transmits the layer information according to the client's request, so that the hierarchical coded information distribution according to the client's request can be performed. When distributing hierarchically encoded data using FGS (Fine Granular Scalability) in MPEG4, a server as a data transmitting device acquires request encoded data information on a client side as a data receiving device, and based on the acquired information, A process of transmitting encoded data in an optimal mode according to a client, that is, a processing sequence of executing an information exchange process by RTSP (Real-time Streaming Protocol) and performing encoded data distribution processing according to a request; This will be described with reference to the sequence diagram of FIG.
[0203]
In step S61, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0204]
Upon receiving the method [DESCRIBE] from the client, in step S62, the server performs a process of transmitting the specification information of the content, that is, the server-maintained data mode identification information to the client according to the SDP (Session Description Protocol). FIG. 30 shows a data format according to SDP notified from the server to the client.
[0205]
The data configuration from v to m in FIG. 30 is the same as the data described in the first embodiment with reference to FIG. [A = control: rtsp: /// vodserver / contents / videoA. [mpg] is information indicating the storage location of the content (videoA.mpg) in the server. This content is encoded data in the MPEG format.
[0206]
In the configuration of the present embodiment, the SDP is extended, and [a = EL: 5] is further defined as a new content attribute (Attribute) in each of the above information. [EL: 5] is information indicating the mode of the encoded data of the content held by the server. EL: 5 is information indicating that the server stores the FGS enhancement layer (Enhancement Layer) information of the MPEG4 encoded data divided into five parts.
[0207]
Returning to FIG. 29, the description of the processing sequence between the server and the client will be continued. In step S62, the client acquires the content specification information from the server, that is, the server retained data mode identification information by SDP. The client can acquire the division information [EL: 5] of the FGS enhancement layer (Enhancement Layer) as encoded data information from the SDP.
[0208]
The client determines the requested encoded data information corresponding to the encoded image data desired by the client based on the encoded data information of the server included in the received SDP. For example, when it is desired to request acquisition of information corresponding to EL: 3 as the FGS enhancement layer, a reproduction request method [PLAY] in which EL: 3 is set as request encoded data information is transmitted to the server.
[0209]
The processing from the reception of the SDP by the client to the transmission of the PLAY method will be described with reference to the flow shown in FIG. When the client receives the SDP from the server in step S551, in step S552, the client transmits the image quality information, in this case, the division information [EL: 5] of the FGS enhancement layer (Enhancement Layer) of the MPEG4 encoded data held by the server from the SDP. get.
[0210]
Next, in step S553, the required image quality: B is provisionally set based on information such as the CPU, decoder, and display of the client. Required image quality: B is a value set corresponding to the division information [EL] of the FGS enhancement layer of the MPEG4 encoded data, and is a value in the range of 0 to 5. Here, for example, it is assumed that 3 as the EL value corresponds to the required image quality: B. In step S554, division information [EL: 5] of the enhancement layer (Enhancement Layer) of the encoded data held by the server acquired from the SDP is compared with the required image quality: B (= 3).
[0211]
Since data exceeding the required image quality is wasted in transmission processing or decoding processing, if EL> B, in step S555, an update processing is performed to set EL = EL-1. This updating process is executed until the determination condition EL> B in step S554 is determined to be NO.
[0212]
If the determination of EL> B is No, in step S556, the request coded data information corresponding to the coded data mode desired by the client is determined. Here, EL: 3 corresponding to the required image quality: B is determined.
[0213]
In step S557, the client stores the determined request coded data information in the play [PLAY] method as an additional header and transmits the information to the server. FIG. 32A shows the data configuration of the play [PLAY] method of RTSP transmitted from the client to the server.
[0214]
[PLAY rtsp: /// server / contents / videoA. [mpg RTSP / 1.0] is a request to reproduce video information (VideoA) as requested content, that is, information indicating a play method. videoA. mpg indicates that the data is MPEG encoded data. Other information is the same as in the first embodiment, and a description thereof will not be repeated.
[0215]
[EL: 3] described in the lowermost row of FIG. 32A is a header newly defined in the present embodiment, and the encoded data that the client wants to receive is an enhancement layer (Enhancement Layer). Indicates that the data is data up to the level of [EL: 3]. FIG. 32B shows acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client.
[0216]
In the sequence diagram shown in FIG. 29, in the ACK transmission in step S64, the ACK data shown in FIG. 32B is transmitted to the client, and subsequently, in step S65, the encoded data requested by the client, that is, the MPEG encoded data Is extracted, and the encoded data of the enhancement layer corresponding to EL: 3 is extracted, and stream distribution is performed to the client using the RTP packet generated using the extracted data as a payload. The encoded data extraction processing is executed as the same processing as the processing described in each of the above embodiments.
[0219]
[Example 7]
In the sixth embodiment described above, when distributing hierarchically encoded data using FGS (Fine Granular Scalability) in MPEG4, the server on the data transmission side executes division of an enhancement layer (Enhancement Layer) in advance to transmit transmission data. The configuration example in which the client side specifies the division layer to be included in the above has been described. The enhancement layer (Enhancement Layer) can be divided at an arbitrary position.
[0218]
In order to determine the data amount of the enhancement layer (Enhancement Layer) transmitted from the server to the client, PSNR (Peak Signal to PSNR) as information of signal-to-noise ratio which is one of image quality information of distribution data (content) is determined. A configuration example using Noise Ratio) will be described as a seventh embodiment.
[0219]
As described above, the enhancement layer is data that is encoded using an embedded DCT compression method or the like based on the base layer and the original image. Although the minimum image quality can be obtained only with the base layer, a higher quality image can be obtained by adjusting the enhancement layer. The image quality is improved when the enhancement layer (Enhancement Layer) is added more. That is, the image quality is determined by the added amount of the enhancement layer (Enhancement Layer). The value of PSNR (Peak Signal to Noise Ratio) as the image quality index value increases as the amount of enhancement layer (Enhancement Layer) added increases.
[0220]
FIG. 33 shows a correspondence between a base layer (BL) and a PSNR (Peak Signal to Noise Ratio) as an image quality index value according to an added amount of an enhancement layer (Enhancement Layer). As shown in FIG. 33, data (EL = 0) of only the base layer (BL: Base Layer) has a low PSNR value, but as the added amount of the enhancement layer (Enhancement Layer) increases, The PSNR value increases and the image quality improves.
[0221]
In this embodiment, the client specifies the PSNR value, and the server determines the amount of information of the enhancement layer to be transmitted to the client according to the specified PSNR value, and executes data transmission.
[0222]
A data communication processing sequence executed between the server and the client according to the present embodiment will be described with reference to the sequence diagram of FIG. In step S71, the client transmits a method [DESCRIBE] specified in RTSP to the server. Describing [DESCRIBE] is a method for executing a content specification request, for example, transmitting a content identifier and making a content specification request.
[0223]
Upon receiving the method [DESCRIBE] from the client, in step S72, the server executes a process of transmitting the specification information of the content, that is, the server retained data mode identification information to the client according to the SDP (Session Description Protocol). FIG. 35 shows a data format according to SDP notified from the server to the client.
[0224]
The data configuration from v to a in FIG. 35 is the same as the data shown in FIG. 30 in the sixth embodiment. In the configuration of the present embodiment, the SDP is extended, and [a = PSNR: 45] is further defined as a new content attribute (Attribute) in each of the above information. [PSNR: 45] is information indicating the mode of the encoded data of the content held by the server. PSNR: 45 indicates a value of PSNR (Peak Signal to Noise Ratio) as the highest image quality information obtained by decoding all information of the FGS enhancement layer (Enhancement Layer) of the MPEG4 encoded data held by the server.
[0225]
Returning to FIG. 34, the description of the processing sequence between the server and the client will be continued. In step S72, the client acquires the content specification information from the server, that is, the server retained data mode identification information by SDP. The client can obtain a PSNR (Peak Signal to Noise Ratio) value [PSNR: 45] as the highest image quality information of the MPEG4 encoded data held by the server as encoded data information from the SDP.
[0226]
The client determines the requested encoded data information corresponding to the encoded image data desired by the client based on the encoded data information of the server included in the received SDP. For example, [PSNR: 30] is set as the value of PSNR as the image quality information. This value is determined based on the specifications of the CPU, decoder, display, and the like of the client device.
[0227]
The processing from the reception of the SDP to the transmission of the PLAY method in the client will be described with reference to the flow shown in FIG. Upon receiving the SDP from the server in step S571, the client acquires image quality information, in this case, the highest image quality index value of the MPEG4 encoded data held by the server: A [PSNR: 45] from the SDP in step S572.
[0228]
Next, in step S573, a required image quality index value: B [PSNR: 30] is set based on information of the CPU, decoder, display, and the like of the client. In step S574, it is determined whether or not the highest image quality index value: A [PSNR: 45] of the MPEG4 encoded data held by the server acquired from the SDP matches the required image quality index value: B [PSNR: 30]. I do.
[0229]
Since data exceeding the required image quality is wasted in transmission processing or decoding processing, if A ≠ B, an update processing in which A = B is executed in step S575. If A = B holds, in step S576, the client determines request encoded data information corresponding to the encoded data mode that the client wants to receive. Here, it is assumed that PSNR: 30 corresponding to required image quality: B is determined.
[0230]
In step S577, the client stores the determined calculation request encoded data information in the play [PLAY] method as an additional header and transmits the information to the server. FIG. 37A shows the data structure of the RTSP play [PLAY] method transmitted from the client to the server. [PLAY rtsp: /// server / contents / videoA. [mpg RTSP / 1.0] is a request to reproduce video information (VideoA) as requested content, that is, information indicating a play method. videoA. mpg indicates that the data is MPEG encoded data. Other information is the same as in the first embodiment, and a description thereof will not be repeated.
[0231]
[PSNR: 30] described in the bottom row of FIG. 37A is a header newly defined in the present embodiment, and the encoded data that the client wants to receive is PSNR: 30 as the image quality index value. Indicates that the data can be reproduced. FIG. 37B shows acknowledgment [ACK] data transmitted to the client by the server that has received the RTSP play [PLAY] method from the client.
[0232]
In the sequence diagram shown in FIG. 34, in the ACK transmission in step S74, the ACK data shown in FIG. 37B is transmitted to the client, and subsequently, in step S75, the encoded data requested by the client, that is, the MPEG encoded data And encoded data of an image-reproducible enhancement layer having PSNR: 30 as an image quality index value are extracted, and stream distribution using RTP packets with the extracted data as a payload is performed to the client. Executed.
[0233]
On the server side, according to the PSNR value received from the client, the EL addition amount is determined based on the correspondence between the EL addition amount and the PSNR in FIG. 33 described above, and the determined EL data and the base layer ( BL) data is stored as a payload of a communication packet and transmitted to the client.
[0234]
In the sixth and seventh embodiments, the compression processing to which the FGS (Fine Granular Scalability) technology by MPEG4 is applied is a moving image compression method based on DCT, but is not limited to the MPEG data format. Even when the prescribed JVT (Joint Video Team) is applied, it is possible to execute the selection and transmission processing of the hierarchically encoded data in accordance with the client request, similarly to the above-described processing.
[0235]
[Example of data transmission / reception device configuration]
FIG. 38 illustrates a configuration example of a data transmission device and a data reception device corresponding to a server and a client that execute the series of processes described in the above-described embodiment. The data transmitted and received by the system of the present invention is hierarchically encoded data, and the data transmitting device performs an encoding process and the data receiving device performs a decoding process. The encoded data is transmitted and received as an IP packet via a network. Therefore, the data transmission side executes packet generation (packetizing processing), and the data receiving side executes packet expansion (depacketizing processing).
[0236]
A data transmission / reception device (ex. PC) 850 illustrated in FIG. 38 functions as a codec 851 that executes encoding (encoding) processing and decoding (decoding) processing, performs packet generation and expansion processing, and interfaces with a communication network. Network interface 852, input / output interface 853 with input devices such as mouse 837 and keyboard 836, AV interface 854 for inputting and outputting data from AV data input / output devices such as video camera 833, microphone 834, speaker 835, and display 832. Display interface 855 as a data output interface, data input / output interfaces, codec 851, data transfer control between network interfaces 852, and other various program controls CPU 856 to execute, storage of various programs controlled and executed by CPU 856, storage of data, RAM 857 functioning as a work area of CPU 856, memory 857 including ROM, data storage, HDD 858 as a storage medium for storing programs, Each is connected to a PCI bus 859 and has a configuration capable of mutually transmitting and receiving data.
[0237]
As shown in FIG. 38, the codec 851 receives, for example, image data from the video camera 833 and audio data from the microphone 834, performs hierarchical coding processing, and stores the data in the HDD 858 as a storage unit. The server selectively extracts encoded data from the storage unit under the control of the CPU 856 as a control unit in response to a request from the client, adjusts the arrangement as necessary, and performs packet generation processing (packetizing). And finally generate an IP packet with the hierarchically encoded data as a payload. The generated IP packet is output on the PCI bus 859, output to the network via the network interface 852, and distributed to, for example, a destination address set in the header of the IP packet.
[0238]
Also, under the control of the CPU 856 in accordance with a software encoding program stored in the HDD 858 or the memory 857, the image data from the video camera 833 and the audio data from the microphone 834 are hierarchically encoded and output to the network via the network interface 852. It is good also as composition which enabled processing.
[0239]
On the other hand, IP packetized data input via the network is output to the bus 859 via the network interface 852 and input to the codec 851. The codec 851 executes packet expansion processing (depacketizing) of input data, extracts hierarchically encoded data stored as a payload, executes decoding processing, and reproduces and outputs the data on the display 832 and the speaker 835.
[0240]
In the above-described embodiment, data such as an image to be coded is input from a camera or other input device, for example, a data input device such as a scanner, a flexible disk, a CD-ROM (Compact Disc Read Only Memory), or an MO (Magneto optical). ) It can be input from a removable recording medium such as a disk, a DVD (Digital Versatile Disc), a magnetic disk, and a semiconductor memory.
[0241]
The CPU 856 loads not only the ROM storage program but also a program stored on the hard disk, a program transferred from a satellite or a network, and received and installed into a memory such as a RAM (Random Access Memory). It is also possible to do it.
[0242]
The present invention has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the spirit of the present invention. That is, the present invention has been disclosed by way of example, and should not be construed as limiting. In order to determine the gist of the present invention, the claims described at the beginning should be considered.
[0243]
Note that the series of processes described in the specification can be executed by hardware, software, or a combined configuration of both. When executing the processing by software, the program recording the processing sequence is installed in a memory in a computer embedded in dedicated hardware and executed, or the program is stored in a general-purpose computer capable of executing various processing. It can be installed and run.
[0244]
For example, the program can be recorded in a hard disk or a ROM (Read Only Memory) as a recording medium in advance. Alternatively, the program is temporarily or permanently stored on a removable recording medium such as a flexible disk, a CD-ROM (Compact Disc Only Memory), an MO (Magneto optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, or a semiconductor memory. It can be stored (recorded). Such a removable recording medium can be provided as so-called package software.
[0245]
The program is installed in the computer from the removable recording medium as described above, and is wirelessly transferred from the download site to the computer, or is transferred to the computer by wire via a network such as a LAN (Local Area Network) or the Internet. The computer can receive the program transferred in this way and install it on a recording medium such as a built-in hard disk.
[0246]
The various processes described in the specification may be executed not only in chronological order according to the description but also in parallel or individually according to the processing capability of the device that executes the processes or as necessary. Further, in this specification, a system is a logical set configuration of a plurality of devices, and is not limited to a device having each configuration in the same housing.
[0247]
【The invention's effect】
As described above, according to the configuration of the present invention, in the server-client system including the server that executes the transmission processing of the hierarchically encoded data and the client that receives the hierarchically encoded data from the server, The request data mode identification information indicating the hierarchically encoded data mode requested by the client is stored in the data request message to be transmitted and transmitted, and the server extracts the encoded data corresponding to the client based on the requested data mode identification information. Alternatively, since the processing for generating and transmitting the generated data to the client is performed, it is possible to transmit optimal data according to the processing capability of the client.
[0248]
Moreover, according to the configuration of the present invention, the server can extract data of various configurations from the only coded data stored in the storage unit as transmission data by extracting data in response to a request from the client. In addition, the server does not need to store a plurality of data of various types, thereby enabling efficient processing.
[0249]
Further, according to the configuration of the present invention, the client executes a process of transmitting a data specification request to the server before transmitting the data request message, and the server transmits a response message storing the server-maintained data mode identification information as a response to the client. And the client can determine the hierarchically encoded data mode requested by the client based on the server-held data mode identification information, and can request data within a range that the server reliably holds.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of a network configuration to which the present invention can be applied.
FIG. 2 is a diagram showing a configuration example of a data transmission device of the present invention.
FIG. 3 is a diagram illustrating an example of a configuration of an encoding process based on a wavelet transform.
FIG. 4 is a diagram illustrating a wavelet transform process.
FIG. 5 is a diagram illustrating an encoded data configuration of the data transmission device of the present invention.
FIG. 6 is a diagram illustrating a configuration example of JPEG200 encoded data included in the data transmission device of the present invention.
FIG. 7 is a diagram showing a communication sequence between a server and a client in the first embodiment of the present invention.
FIG. 8 is a diagram showing an example of message data transmitted from a server to a client in the first embodiment of the present invention.
FIG. 9 is a flowchart showing processing from reception of an SDP to transmission of a play method in the client according to the first embodiment of the present invention.
FIG. 10 is a diagram illustrating an example of a message transmitted from a client and response data from a server in the first embodiment of the present invention.
FIG. 11 is a flowchart showing processing from reception of a PLAY method to transmission of encoded data in the server according to the first embodiment of the present invention.
FIG. 12 is a diagram showing a configuration of encoded data transmitted from a server to a client in the first embodiment of the present invention.
FIG. 13 is a diagram showing a communication sequence between a server and a client in the second embodiment of the present invention.
FIG. 14 is a diagram illustrating an example of a message transmitted by a client and response data from a server in the second embodiment of the present invention.
FIG. 15 is a flowchart showing processing from reception of a PLAY method to transmission of encoded data in the server according to the second embodiment of the present invention.
FIG. 16 is a diagram showing a configuration of encoded data transmitted from a server to a client in a second embodiment of the present invention.
FIG. 17 is a diagram showing a communication sequence between a server and a client in the third embodiment of the present invention.
FIG. 18 is a flowchart showing processing from reception of an SDP to transmission of a play method in a client according to the third embodiment of the present invention.
FIG. 19 is a diagram illustrating an example of a transmission message of a client and response data from a server in a third embodiment of the present invention.
FIG. 20 is a flowchart showing processing from reception of a PLAY method to transmission of encoded data in the server according to the third embodiment of the present invention.
FIG. 21 is a diagram illustrating a configuration of encoded data transmitted from a server to a client in a third embodiment of the present invention.
FIG. 22 is a diagram showing a communication sequence between a server and a client in a fourth embodiment of the present invention.
FIG. 23 is a diagram showing a communication sequence between a server and a client in the fifth embodiment of the present invention.
FIG. 24 is a diagram illustrating an example of message data transmitted from a server to a client according to a fifth embodiment of the present invention.
FIG. 25 is a flowchart showing processing from reception of an SDP to transmission of a play method in a client according to a fifth embodiment of the present invention.
FIG. 26 is a diagram illustrating an example of a message transmitted by a client and response data from a server according to a fifth embodiment of the present invention.
FIG. 27 is a view for explaining a hierarchically encoded data structure by MPEG.
FIG. 28 is a diagram illustrating an example of dividing hierarchically encoded data by MPEG.
FIG. 29 is a diagram showing a communication sequence between a server and a client in the sixth embodiment of the present invention.
FIG. 30 is a diagram illustrating an example of message data transmitted from a server to a client according to a sixth embodiment of the present invention.
FIG. 31 is a flowchart showing processing from reception of an SDP to transmission of a play method in a client according to a sixth embodiment of the present invention.
FIG. 32 is a diagram illustrating an example of a transmission message of a client and response data from a server according to a sixth embodiment of the present invention.
FIG. 33 is a diagram illustrating a correspondence between an enhancement layer addition amount of MPEG hierarchical coded data and image quality (PSNR).
FIG. 34 is a diagram showing a communication sequence between a server and a client in the seventh embodiment of the present invention.
FIG. 35 is a diagram illustrating an example of message data transmitted from a server to a client in a seventh embodiment of the present invention.
FIG. 36 is a flowchart showing processing from reception of an SDP to transmission of a play method in a client according to a seventh embodiment of the present invention.
FIG. 37 is a diagram illustrating an example of a transmission message of a client and response data from a server in a seventh embodiment of the present invention.
FIG. 38 is a diagram illustrating a system configuration example of a data transmission device and a data reception device.
[Explanation of symbols]
11 Server
12 Network
13 base stations
21,22,23 Client
100 servers
101 control unit
102 Encoder
103 storage unit
104 communication packet processing unit
105 Data Transmission / Reception Unit
859 PCI bus
832 display
833 video camera
834 microphone
835 speaker
837 mouse
838 keyboard
850 data transceiver
851 codec
852 network interface
853 I / O interface
854 AV interface
855 display interface
856 CPU
857 memory
858 HDD

Claims (39)

階層符号化データの送信処理を実行するサーバと、前記サーバから階層符号化データを受信するクライアントからなるサーバクライアントシステムであり、
前記クライアントは、
前記サーバに対して送信するデータ要求メッセージに、クライアントの要求する階層符号化データ態様を示す要求データ態様識別情報を格納して送信する処理を実行する構成を有し、
前記サーバは、
前記クライアントから受信するデータ要求メッセージに含まれる前記要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成し、前記クライアントに対して送信する処理を実行する構成を有することを特徴とするサーバクライアントシステム。A server that performs a process of transmitting hierarchically encoded data, and a server client system including a client that receives hierarchically encoded data from the server,
The client,
The data request message to be transmitted to the server has a configuration for executing a process of storing and transmitting request data mode identification information indicating the hierarchically encoded data mode requested by the client,
The server comprises:
A process of extracting or generating encoded data corresponding to the request data mode identification information from a storage unit based on the request data mode identification information included in the data request message received from the client, and transmitting the encoded data to the client A server client system having a configuration for executing 前記クライアントは、
制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であり、
前記サーバは、
前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行する構成であることを特徴とする請求項１に記載のサーバクライアントシステム。The client,
A process of storing the request data mode identification information in a description of a play [PLAY] method in accordance with an RTSP (Real-time Streaming Protocol) as a control information communication protocol and transmitting the request data mode identification information to the server;
The server comprises:
A configuration in which the request data mode identification information is acquired from the description of a play [PLAY] method received from the client, and extraction or generation processing of encoded data corresponding to the acquired request data mode identification information is executed. The server client system according to claim 1, wherein: 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする請求項１に記載のサーバクライアントシステム。The hierarchically encoded data is JPEG2000 format data,
The server client system according to claim 1, wherein the request data mode identification information includes at least one of resolution information and image quality information. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、１フレームあたりのＪＰＥＧ２０００符号化データパケット（ＪＰ２パケット）数であることを特徴とする請求項１に記載のサーバクライアントシステム。The hierarchically encoded data is JPEG2000 format data,
2. The server client system according to claim 1, wherein the request data mode identification information is the number of JPEG2000 encoded data packets (JP2 packets) per frame. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする請求項１に記載のサーバクライアントシステム。The hierarchically encoded data is JPEG2000 format data,
The request data mode identification information includes LRCP (Layer-resolution level-component-position progress) as a progression type in JPEG2000 encoded data, or RLCP (Resolution level-layer-component-position designated information including any one of the resolution-position-information-relation-position-information). The server client system according to claim 1, wherein: 前記要求データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする請求項１に記載のサーバクライアントシステム。The request data mode identification information includes at least one of an R value corresponding to a wavelet transform count value associated with a generation process of hierarchically encoded data and an L value corresponding to a layer number. Item 2. The server-client system according to item 1. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする請求項１に記載のサーバクライアントシステム。The hierarchically encoded data is MPEG format data,
2. The server client system according to claim 1, wherein the request data mode identification information is a division number of an enhancement layer in the MPEG encoded data. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏＮｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする請求項１に記載のサーバクライアントシステム。The hierarchically encoded data is MPEG format data,
2. The server according to claim 1, wherein the request data mode identification information is a value of a PSNR (Peak Signal to Noise Ratio) as an image quality index value for determining an information amount of an enhancement layer in the MPEG encoded data. 3. Client system. 前記クライアントは、前記データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行し、前記サーバは、前記クライアントから受信するデータ仕様要求の応答として、サーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信する処理を実行する構成であり、
前記クライアントは、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、クライアントの要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報として前記データ要求メッセージに格納して前記サーバに送信する処理を実行する構成であることを特徴とする請求項１に記載のサーバクライアントシステム。The client executes a process of transmitting a data specification request to a server before transmitting the data request message, and the server responds to the data specification request received from the client by storing a server-maintained data mode identification information. It is configured to execute a process of transmitting a message to the client,
The client obtains server-maintained data mode identification information from a response message received from the server, determines a hierarchically encoded data mode requested by the client based on the obtained information, and stores the determination information in the request data. The server client system according to claim 1, wherein the server client system is configured to execute a process of storing the data in the data request message as aspect identification information and transmitting the data to the server. 前記クライアントは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったデスクライブ［ＤＥＳＣＲＩＢＥ］メソッドによりデータ仕様要求を前記サーバに送信し、
前記サーバは、前記クライアントから受信する前記デスクライブ［ＤＥＳＣＲＩＢＥ］メソッドの応答として、サーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信し、
前記クライアントは、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、クライアントの要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報としてＲＴＳＰに従ったプレイ［ＰＬＡＹ］メソッドの記述中に格納して前記サーバに送信する処理を実行する構成であることを特徴とする請求項９に記載のサーバクライアントシステム。The client sends a data specification request to the server by a description [DESCRIBE] method according to RTSP (Real-time Streaming Protocol) as a control information communication protocol,
The server transmits to the client a response message storing server-maintained data mode identification information as a response to the describable [DESCRIBE] method received from the client;
The client obtains server-maintained data mode identification information from a response message received from the server, determines a hierarchically encoded data mode requested by the client based on the obtained information, and stores the determination information in the request data. 10. The server client system according to claim 9, wherein the server client system is configured to execute a process of storing in a description of a play [PLAY] method according to RTSP as mode identification information and transmitting the mode to the server. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする請求項９に記載のサーバクライアントシステム。The hierarchically encoded data is JPEG2000 format data,
10. The server client system according to claim 9, wherein the request data mode identification information and the server held data mode identification information include at least one of resolution information and image quality information. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする請求項９に記載のサーバクライアントシステム。The hierarchically encoded data is JPEG2000 format data,
The request data mode identification information and the server held data mode identification information are LRCP (Layer-resolution level-component-position progression) or RLCP (Resolution level-component-component-component) as a progression type in JPEG2000 encoded data. 10. The server client system according to claim 9, wherein the server client system includes any one of the specified information. 前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする請求項９に記載のサーバクライアントシステム。The request data mode identification information and the server-maintained data mode identification information each include at least one of an R value corresponding to a wavelet transform count value associated with a hierarchically encoded data generation process and an L value corresponding to a layer number. The server-client system according to claim 9, comprising: 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする請求項９に記載のサーバクライアントシステム。The hierarchically encoded data is MPEG format data,
10. The server client system according to claim 9, wherein the request data mode identification information and the server retained data mode identification information are the number of divisions of an enhancement layer in MPEG encoded data. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする請求項９に記載のサーバクライアントシステム。The hierarchically encoded data is MPEG format data,
The request data mode identification information and the server-maintained data mode identification information are PSNR (Peak Signal to Noise Ratio) values as image quality index values that determine the information amount of the enhancement layer in the MPEG encoded data. The server client system according to claim 9, wherein 階層符号化データの送信処理を実行するサーバとしてのデータ送信装置であり、
クライアントとのデータ送受信を実行する通信部と、
前記通信部を介してクライアントから受信するデータ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御部と、
前記制御部の制御の下に抽出または生成した符号化データを格納した通信パケットを生成する通信パケット処理部とを有し、
前記通信パケット処理部において生成したクライアント対応の符号化データを格納した通信パケットをクライアントに対して送信する処理を実行する構成を有することを特徴とするデータ送信装置。A data transmission device as a server that performs a transmission process of the hierarchically encoded data,
A communication unit for transmitting and receiving data to and from the client;
A control unit that extracts or generates encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message received from the client via the communication unit;
Having a communication packet processing unit that generates a communication packet storing the encoded data extracted or generated under the control of the control unit,
A data transmission device having a configuration for executing a process of transmitting a communication packet storing encoded data corresponding to a client generated in the communication packet processing unit to a client. 前記クライアントは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であり、
前記制御部は、
前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行する構成であることを特徴とする請求項１６に記載のデータ送信装置。A configuration in which the client stores the request data mode identification information in the description of a play [PLAY] method according to a real-time streaming protocol (RTSP) as a control information communication protocol and transmits the request data mode identification information to the server. And
The control unit includes:
A configuration in which the request data mode identification information is acquired from the description of a play [PLAY] method received from the client, and extraction or generation processing of encoded data corresponding to the acquired request data mode identification information is executed. The data transmission device according to claim 16, wherein: 前記データ送信装置は、
前記通信部を介してクライアントからデータ仕様要求を受信し、
前記制御部は、
記憶部に格納した階層符号化データの態様情報としてのサーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信する処理を実行する構成であることを特徴とする請求項１６に記載のデータ送信装置。The data transmission device,
Receiving a data specification request from the client via the communication unit,
The control unit includes:
17. The data according to claim 16, wherein the server executes a process of transmitting a response message storing server retained data aspect identification information as aspect information of the hierarchically encoded data stored in the storage unit to the client. Transmission device. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記サーバ保持データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする請求項１８に記載のデータ送信装置。The hierarchically encoded data is JPEG2000 format data,
19. The data transmitting apparatus according to claim 18, wherein the server held data mode identification information includes at least one of resolution information and image quality information. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記サーバ保持データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする請求項１８に記載のデータ送信装置。The hierarchically encoded data is JPEG2000 format data,
The server-holding data mode identification information may be LRCP (Layer-resolution level-component-position progress) or RLCP (Resolution level-layer-component designation information) as a progression type in JPEG2000 encoded data. 19. The data transmission device according to claim 18, comprising: 前記サーバ保持データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする請求項１８に記載のデータ送信装置。The server-held data mode identification information includes at least one piece of designation information of an R value corresponding to a wavelet transform count value associated with a generation process of hierarchically encoded data or an L value corresponding to the number of layers. The data transmission device according to claim 18. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする請求項１８に記載のデータ送信装置。The hierarchically encoded data is MPEG format data,
19. The data transmitting apparatus according to claim 18, wherein the server-maintained data mode identification information is a division number of an enhancement layer in MPEG encoded data. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報および前記サーバ保持データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする請求項１８に記載のデータ送信装置。The hierarchically encoded data is MPEG format data,
The request data mode identification information and the server-maintained data mode identification information are PSNR (Peak Signal to Noise Ratio) values as image quality index values that determine an information amount of an enhancement layer in MPEG encoded data. The data transmission device according to claim 18, wherein: サーバから階層符号化データを受信するクライアントとしてのデータ受信装置であり、
前記データ受信装置は、
サーバとのデータ送受信を実行する通信部と、
自己の要求する階層符号化データ態様の決定処理を実行し、決定情報を前記通信部を介してサーバに送信するデータ要求メッセージに格納する要求データ態様識別情報として設定する制御部とを有し、
サーバに対する階層符号化データの要求メッセージ中に、前記要求データ態様識別情報を格納して送信する処理を実行する構成を有することを特徴とするデータ受信装置。A data receiving device as a client that receives hierarchically encoded data from a server,
The data receiving device,
A communication unit for transmitting and receiving data to and from the server;
A control unit that performs a process of determining a hierarchically encoded data mode requested by itself, and sets the determination information as request data mode identification information to be stored in a data request message transmitted to the server via the communication unit,
A data receiving apparatus having a configuration for executing processing for storing and transmitting the request data mode identification information in a request message for hierarchically encoded data to a server. 前記データ受信装置は、
制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドの記述中に前記要求データ態様識別情報を格納して前記サーバに送信する処理を実行する構成であることを特徴とする請求項２４に記載のデータ受信装置。The data receiving device,
It is configured to execute a process of storing the request data mode identification information in a description of a play [PLAY] method according to an RTSP (Real-time Streaming Protocol) as a control information communication protocol and transmitting the information to the server. The data receiving device according to claim 24, wherein 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、解像度情報、画質情報の少なくともいすれかの情報を含むことを特徴とする請求項２４に記載のデータ受信装置。The hierarchically encoded data is JPEG2000 format data,
The data receiving apparatus according to claim 24, wherein the request data mode identification information includes at least one of resolution information and image quality information. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、１フレームあたりのＪＰＥＧ２０００符号化データパケット（ＪＰ２パケット）数であることを特徴とする請求項２４に記載のデータ受信装置。The hierarchically encoded data is JPEG2000 format data,
The data receiving apparatus according to claim 24, wherein the request data mode identification information is the number of JPEG2000 encoded data packets (JP2 packets) per frame. 前記階層符号化データは、ＪＰＥＧ２０００フォーマットデータであり、
前記要求データ態様識別情報は、ＪＰＥＧ２０００符号化データにおけるプログレッションタイプとしてのＬＲＣＰ（Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）、またはＲＬＣＰ（Ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｌａｙｅｒ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ）いずれかの指定情報を含むことを特徴とする請求項２４に記載のデータ受信装置。The hierarchically encoded data is JPEG2000 format data,
The request data mode identification information includes LRCP (Layer-resolution level-component-position progression) as a progression type in JPEG2000 encoded data, or RLCP (Resolution level-layer-component-position-specification information including any one of the resolution specification information). 25. The data receiving apparatus according to claim 24, wherein: 前記要求データ態様識別情報は、階層符号化データの生成処理に伴うウェーブレット変換回数値に相当するＲ値、またはレイヤ数に相当するＬ値の少なくともいずれかの指定情報を含むことを特徴とする請求項２４に記載のデータ受信装置。The request data mode identification information includes at least one of an R value corresponding to a wavelet transform count value associated with a generation process of hierarchically encoded data and an L value corresponding to a layer number. Item 25. The data receiving device according to item 24. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの分割数であることを特徴とする請求項２４に記載のデータ受信装置。The hierarchically encoded data is MPEG format data,
25. The data receiving apparatus according to claim 24, wherein the request data mode identification information is a division number of an enhancement layer in MPEG encoded data. 前記階層符号化データは、ＭＰＥＧフォーマットデータであり、
前記要求データ態様識別情報は、ＭＰＥＧ符号化データにおけるエンハンスメント・レイヤの情報量を決定する画質指標値としてのＰＳＮＲ（Ｐｅａｋ Ｓｉｇｎａｌ ｔｏＮｏｉｓｅ Ｒａｔｉｏ）の値であることを特徴とする請求項２４に記載のデータ受信装置。The hierarchically encoded data is MPEG format data,
25. The data according to claim 24, wherein the request data mode identification information is a value of a PSNR (Peak Signal to Noise Ratio) as an image quality index value for determining an information amount of an enhancement layer in the MPEG encoded data. Receiver. 前記データ受信装置は、前記データ要求メッセージの送信前にサーバに対するデータ仕様要求の送信処理を実行するとともに、前記サーバから受信する応答メッセージ中からサーバ保持データ態様識別情報を取得し、該取得情報に基づいて、自己の要求する階層符号化データ態様を決定し、該決定情報を前記要求データ態様識別情報として前記データ要求メッセージに格納して前記サーバに送信する処理を実行する構成であることを特徴とする請求項２４に記載のデータ受信装置。The data receiving device executes a process of transmitting a data specification request to a server before transmitting the data request message, and acquires server retained data mode identification information from a response message received from the server, and And determining the hierarchically encoded data mode requested by the server, storing the determined information in the data request message as the requested data mode identification information, and transmitting the determined information to the server. The data receiving apparatus according to claim 24, wherein: 階層符号化データの送信処理を実行するデータ送信方法であり、
クライアントからデータ要求メッセージを受信するステップと、
前記データ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御ステップと、
抽出または生成した符号化データを格納した通信パケットを生成する通信パケット生成ステップと、
クライアント対応の符号化データを格納した通信パケットをクライアントに対して送信するステップと、
を有することを特徴とするデータ送信方法。A data transmission method for performing a transmission process of hierarchically encoded data,
Receiving a data request message from a client;
A control step of extracting or generating encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message;
A communication packet generating step of generating a communication packet storing the extracted or generated encoded data,
Transmitting a communication packet containing encoded data corresponding to the client to the client;
A data transmission method comprising: 前記制御ステップは、
前記クライアントから受信するプレイ［ＰＬＡＹ］メソッドの記述中から、前記要求データ態様識別情報を取得し、取得した要求データ態様識別情報に対応する符号化データの抽出または生成処理を実行するステップであることを特徴とする請求項３３に記載のデータ送信方法。The control step includes:
A step of acquiring the request data mode identification information from the description of a play [PLAY] method received from the client, and executing a process of extracting or generating encoded data corresponding to the acquired request data mode identification information. 34. The data transmission method according to claim 33, wherein: 前記データ送信方法は、さらに、
前記通信部を介してクライアントからデータ仕様要求を受信するステップと、
記憶部に格納した階層符号化データの態様情報としてのサーバ保持データ態様識別情報を格納した応答メッセージを前記クライアントに送信するステップと、
を有することを特徴とする請求項３３に記載のデータ送信方法。The data transmission method further includes:
Receiving a data specification request from a client via the communication unit;
Transmitting, to the client, a response message storing server-maintained data mode identification information as mode information of the hierarchically encoded data stored in the storage unit;
The data transmission method according to claim 33, further comprising: サーバに対する階層符号化データの要求処理を実行するデータ要求処理方法であり、
自己の要求する階層符号化データ態様の決定処理を実行する要求データ態様決定ステップと、
サーバに送信するデータ要求メッセージに前記決定ステップにおいて決定した要求データ態様を要求データ態様識別情報として格納するステップと、
前記データ要求メッセージをサーバに対して送信するステップと、
を有することを特徴とするデータ要求処理方法。A data request processing method for performing a request processing of hierarchically encoded data to a server,
A request data mode determining step of executing a hierarchically encoded data mode determining process requested by itself,
Storing the request data mode determined in the determination step in the data request message to be transmitted to the server as request data mode identification information;
Sending the data request message to a server;
A data request processing method comprising: 前記データ要求メッセージは、制御情報通信プロトコルとしてのＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）に従ったプレイ［ＰＬＡＹ］メソッドとしてサーバに対して送信することを特徴とする請求項３６に記載のデータ要求処理方法。37. The data request processing method according to claim 36, wherein the data request message is transmitted to a server as a play [PLAY] method in accordance with an RTSP (Real-time Streaming Protocol) as a control information communication protocol. . 階層符号化データの送信処理を実行するデータ送信処理を実行するコンピュータ・プログラムであって、
クライアントからデータ要求メッセージを受信するステップと、
前記データ要求メッセージに含まれる要求データ態様識別情報に基づいて、該要求データ態様識別情報に対応する符号化データを記憶部から抽出または生成する制御ステップと、
抽出または生成した符号化データを格納した通信パケットを生成する通信パケット生成ステップと、
クライアント対応の符号化データを格納した通信パケットをクライアントに対して送信するステップと、
を具備することを特徴とするコンピュータ・プログラム。A computer program for performing a data transmission process of performing a transmission process of the hierarchical encoded data,
Receiving a data request message from a client;
A control step of extracting or generating encoded data corresponding to the request data mode identification information from the storage unit based on the request data mode identification information included in the data request message;
A communication packet generating step of generating a communication packet storing the extracted or generated encoded data,
Transmitting a communication packet containing encoded data corresponding to the client to the client;
A computer program comprising: サーバに対する階層符号化データの要求処理を実行するデータ要求処理を実行するコンピュータ・プログラムであって、
自己の要求する階層符号化データ態様の決定処理を実行する要求データ態様決定ステップと、
サーバに送信するデータ要求メッセージに前記決定ステップにおいて決定した要求データ態様を要求データ態様識別情報として格納するステップと、
前記データ要求メッセージをサーバに対して送信するステップと、
を具備することを特徴とするコンピュータ・プログラム。A computer program for executing a data request process for executing a request process for hierarchically encoded data to a server,
A request data mode determining step of executing a hierarchically encoded data mode determining process requested by itself,
Storing the request data mode determined in the determination step in the data request message to be transmitted to the server as request data mode identification information;
Sending the data request message to a server;
A computer program comprising:
JP2002356980A 2002-12-09 2002-12-09 Data communication system, data transmitting device, data receiving device and method, and computer program Pending JP2004192140A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002356980A JP2004192140A (en) 2002-12-09 2002-12-09 Data communication system, data transmitting device, data receiving device and method, and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002356980A JP2004192140A (en) 2002-12-09 2002-12-09 Data communication system, data transmitting device, data receiving device and method, and computer program

Publications (2)

Publication Number Publication Date
JP2004192140A true JP2004192140A (en) 2004-07-08
JP2004192140A5 JP2004192140A5 (en) 2006-01-26

Family

ID=32757162

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002356980A Pending JP2004192140A (en) 2002-12-09 2002-12-09 Data communication system, data transmitting device, data receiving device and method, and computer program

Country Status (1)

Country Link
JP (1) JP2004192140A (en)

Cited By (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007329747A (en) * 2006-06-08 2007-12-20 Ikegami Tsushinki Co Ltd Image processor and image processing method, and monitor system using the same
JP2009296144A (en) * 2008-06-03 2009-12-17 Mitsubishi Electric Corp Digital video data transmission apparatus, digital video data reception apparatus, digital video data transport system, digital video data transmission method, digital video data reception method, and digital video data transport method
JP2010114814A (en) * 2008-11-10 2010-05-20 Nec Corp Moving image processor
JP2010212942A (en) * 2009-03-10 2010-09-24 Nec Corp System, method, device and program for video distribution
JP2010536232A (en) * 2007-08-23 2010-11-25 サムスン エレクトロニクス カンパニー リミテッド Method and apparatus for determining a preferred image format between mobile videophones
JP2012090016A (en) * 2010-10-18 2012-05-10 Canon Inc Video processing device, control method therefor, and program
JP2012517778A (en) * 2009-02-12 2012-08-02 クゥアルコム・インコーポレイテッド Federated procedures that allow multiple multicast streams
JP2012175626A (en) * 2011-02-24 2012-09-10 Kddi Corp Super-resolution apparatus for distribution video and super-resolution video playback device
JP2013025645A (en) * 2011-07-22 2013-02-04 Canon Inc Information processing apparatus, information processing method, and program
JPWO2011030811A1 (en) * 2009-09-14 2013-02-07 日本電気株式会社 Distribution system, gateway, distribution method and program
JP2013505681A (en) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド Extended block-request streaming with scalable coding
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US8811294B2 (en) 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US8887020B2 (en) 2003-10-06 2014-11-11 Digital Fountain, Inc. Error-correcting multi-stage code generator and decoder for communication systems having single transmitters or multiple transmitters
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US9136983B2 (en) 2006-02-13 2015-09-15 Digital Fountain, Inc. Streaming and buffering using variable FEC overhead and protection periods
US9136878B2 (en) 2004-05-07 2015-09-15 Digital Fountain, Inc. File download and streaming system
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9191151B2 (en) 2006-06-09 2015-11-17 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US9236976B2 (en) 2001-12-21 2016-01-12 Digital Fountain, Inc. Multi stage code generator and decoder for communication systems
US9236885B2 (en) 2002-10-05 2016-01-12 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
US9237101B2 (en) 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US9246633B2 (en) 1998-09-23 2016-01-26 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9264069B2 (en) 2006-05-10 2016-02-16 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient uses of the communications systems
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9898241B2 (en) 2014-04-24 2018-02-20 Ricoh Company, Ltd. Information sharing system, image processing apparatus, and image processing method
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
CN111831693A (en) * 2020-06-05 2020-10-27 北京空间机电研究所 Optical remote sensing load index obtaining method based on numerical correlation analysis
JP7401097B2 (en) 2020-03-19 2023-12-19 日本電気株式会社 IP broadcast system, IP gateway device, management node device, client device and method

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001092706A (en) * 1999-09-21 2001-04-06 Matsushita Electric Ind Co Ltd Data transmitting method, data receiving method and data receiver
JP2001204001A (en) * 1999-10-29 2001-07-27 Matsushita Electric Ind Co Ltd Moving picture distribution system, reproduction terminal and distributor
JP2002112149A (en) * 2000-09-29 2002-04-12 Sony Corp Data processing method and device, data transmission system, transmission medium
JP2002123456A (en) * 2000-10-13 2002-04-26 Canon Inc Method and device for processing image and storage medium
JP2002135594A (en) * 2000-10-20 2002-05-10 Sony Corp Image coder and its method, and image decoder and its method
JP2002149153A (en) * 2000-11-10 2002-05-24 Canon Inc Image processor, image processing system, image processing method and storage medium
EP1233624A1 (en) * 2001-02-15 2002-08-21 Ricoh Company, Ltd. A memory usage scheme for performing wavelet processing

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001092706A (en) * 1999-09-21 2001-04-06 Matsushita Electric Ind Co Ltd Data transmitting method, data receiving method and data receiver
JP2001204001A (en) * 1999-10-29 2001-07-27 Matsushita Electric Ind Co Ltd Moving picture distribution system, reproduction terminal and distributor
JP2002112149A (en) * 2000-09-29 2002-04-12 Sony Corp Data processing method and device, data transmission system, transmission medium
JP2002123456A (en) * 2000-10-13 2002-04-26 Canon Inc Method and device for processing image and storage medium
JP2002135594A (en) * 2000-10-20 2002-05-10 Sony Corp Image coder and its method, and image decoder and its method
JP2002149153A (en) * 2000-11-10 2002-05-24 Canon Inc Image processor, image processing system, image processing method and storage medium
EP1233624A1 (en) * 2001-02-15 2002-08-21 Ricoh Company, Ltd. A memory usage scheme for performing wavelet processing

Cited By (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9246633B2 (en) 1998-09-23 2016-01-26 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9236976B2 (en) 2001-12-21 2016-01-12 Digital Fountain, Inc. Multi stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US9236885B2 (en) 2002-10-05 2016-01-12 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
US8887020B2 (en) 2003-10-06 2014-11-11 Digital Fountain, Inc. Error-correcting multi-stage code generator and decoder for communication systems having single transmitters or multiple transmitters
US9236887B2 (en) 2004-05-07 2016-01-12 Digital Fountain, Inc. File download and streaming system
US9136878B2 (en) 2004-05-07 2015-09-15 Digital Fountain, Inc. File download and streaming system
US9136983B2 (en) 2006-02-13 2015-09-15 Digital Fountain, Inc. Streaming and buffering using variable FEC overhead and protection periods
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US9264069B2 (en) 2006-05-10 2016-02-16 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient uses of the communications systems
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
JP2007329747A (en) * 2006-06-08 2007-12-20 Ikegami Tsushinki Co Ltd Image processor and image processing method, and monitor system using the same
JP4740800B2 (en) * 2006-06-08 2011-08-03 池上通信機株式会社 Image processing apparatus, image processing method, and monitoring system using the same
US9628536B2 (en) 2006-06-09 2017-04-18 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US11477253B2 (en) 2006-06-09 2022-10-18 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9191151B2 (en) 2006-06-09 2015-11-17 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
JP2015133736A (en) * 2007-08-23 2015-07-23 サムスン エレクトロニクス カンパニー リミテッド Method and apparatus for determining preferred image format between mobile video telephones
US8606325B2 (en) 2007-08-23 2013-12-10 Samsung Electronics Co., Ltd. Method and apparatus for determining preferred image format between mobile video telephones
JP2013179654A (en) * 2007-08-23 2013-09-09 Samsung Electronics Co Ltd Method and apparatus for determining preferred image format between mobile video telephones
JP2010536232A (en) * 2007-08-23 2010-11-25 サムスン エレクトロニクス カンパニー リミテッド Method and apparatus for determining a preferred image format between mobile videophones
US9549013B2 (en) 2007-08-23 2017-01-17 Samsung Electronics Co., Ltd. Method and apparatus for determining preferred image format between mobile video telephones
US9237101B2 (en) 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
US8811294B2 (en) 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
JP2009296144A (en) * 2008-06-03 2009-12-17 Mitsubishi Electric Corp Digital video data transmission apparatus, digital video data reception apparatus, digital video data transport system, digital video data transmission method, digital video data reception method, and digital video data transport method
US8755677B2 (en) 2008-11-10 2014-06-17 Nec Corporation Moving-picture processing device and moving-picture processing method
JP2010114814A (en) * 2008-11-10 2010-05-20 Nec Corp Moving image processor
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
JP2012517778A (en) * 2009-02-12 2012-08-02 クゥアルコム・インコーポレイテッド Federated procedures that allow multiple multicast streams
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
JP2010212942A (en) * 2009-03-10 2010-09-24 Nec Corp System, method, device and program for video distribution
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9660763B2 (en) 2009-08-19 2017-05-23 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9876607B2 (en) 2009-08-19 2018-01-23 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
JPWO2011030811A1 (en) * 2009-09-14 2013-02-07 日本電気株式会社 Distribution system, gateway, distribution method and program
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US11770432B2 (en) 2009-09-22 2023-09-26 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US11743317B2 (en) 2009-09-22 2023-08-29 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
JP2013505681A (en) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド Extended block-request streaming with scalable coding
US10855736B2 (en) 2009-09-22 2020-12-01 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9992555B2 (en) 2010-06-29 2018-06-05 Qualcomm Incorporated Signaling random access points for streaming video data
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9602802B2 (en) 2010-07-21 2017-03-21 Qualcomm Incorporated Providing frame packing type information for video coding
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
JP2012090016A (en) * 2010-10-18 2012-05-10 Canon Inc Video processing device, control method therefor, and program
US10382494B2 (en) 2011-01-21 2019-08-13 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US10911498B2 (en) 2011-01-21 2021-02-02 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US9723359B2 (en) 2011-02-04 2017-08-01 Qualcomm Incorporated Low latency wireless display for graphics
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
JP2012175626A (en) * 2011-02-24 2012-09-10 Kddi Corp Super-resolution apparatus for distribution video and super-resolution video playback device
JP2013025645A (en) * 2011-07-22 2013-02-04 Canon Inc Information processing apparatus, information processing method, and program
US9137391B2 (en) 2011-07-22 2015-09-15 Canon Kabushiki Kaisha Information processing apparatus, information processing method, and storage medium storing program
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9898241B2 (en) 2014-04-24 2018-02-20 Ricoh Company, Ltd. Information sharing system, image processing apparatus, and image processing method
JP7401097B2 (en) 2020-03-19 2023-12-19 日本電気株式会社 IP broadcast system, IP gateway device, management node device, client device and method
CN111831693A (en) * 2020-06-05 2020-10-27 北京空间机电研究所 Optical remote sensing load index obtaining method based on numerical correlation analysis
CN111831693B (en) * 2020-06-05 2024-02-09 北京空间机电研究所 Optical remote sensing load index acquisition method based on numerical correlation analysis

Similar Documents

Publication Publication Date Title
JP2004192140A (en) Data communication system, data transmitting device, data receiving device and method, and computer program
KR100631743B1 (en) Method and apparatus for efficient transmission of scalable bitstream
JP4682914B2 (en) Information processing apparatus and method, program, and recording medium
JP5089658B2 (en) Transmitting apparatus and transmitting method
US7385921B2 (en) Data communication system, data transmission and encoding apparatus, data receiving apparatus, data communication method, data transmission method, received-data processing method, and computer program using priority information
US7573877B2 (en) Terminal apparatus, data transmitting apparatus, data transmitting and receiving system, and data transmitting and receiving method
US6836512B2 (en) Spatial scalability for fine granular video encoding
US9083950B2 (en) Information processing apparatus, computer-readable storage medium, and method for sending packetized frequency components of precincts of image data to another device
JP5493471B2 (en) Information processing apparatus and method
JP4392783B2 (en) Movie reproduction system, movie transmission device, movie transmission method, program, and recording medium
US20080317431A1 (en) Remote Edition System, Main Edition Device, Remote Edition Device, Edition Method, Edition Program, and Storage Medium
US20120042048A1 (en) Method and Apparatus for Scalable Compression of Video
JP2002135783A (en) Processing method of variable bit rate for streaming service
KR20040069360A (en) Targeted scalable video multicast based on client bandwidth or capability
JP5515758B2 (en) Image processing apparatus and method
JP5527603B2 (en) Information processing apparatus and information processing method
US20140368672A1 (en) Methods for Deploying Video Monitoring Applications and Services Across Heterogeneous Networks
JP4361430B2 (en) Bidirectional image communication apparatus, processing method thereof, client apparatus, and program
JP4201780B2 (en) Image processing apparatus, image display apparatus and method
Auli-Llinas et al. Enhanced JPEG2000 quality scalability through block-wise layer truncation
JP4740800B2 (en) Image processing apparatus, image processing method, and monitoring system using the same
JP2006033506A (en) Remote editing system, main editing apparatus, remote editing apparatus, editing method, editing program, and storage medium
JP2004072147A (en) Image distribution system, image reproducing system, and image distribution reproducing system
Qiao et al. Motion-JPEG2000 Stream Scaling for Multi-Resolution Video Transmission
JP2004040526A (en) System for distributing image and system for distributing and reproducing image

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051206

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20051206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080417

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080430

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090526

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090723

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100427