送信装置、送信方法
【課題】 外部の装置に格納されているコンテナ形式のリソースの部分データを、部分データに適した圧縮形式で取得する為の技術を提供すること。
【解決手段】 マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを受信装置１２０から受信する。マルチメディアデータから第１の記述により規定されている部分を部分データとして抽出する。第２の記述により規定されている方式に対応する係数を取得する。取得した係数に応じた値が閾値よりも大きい場合、部分データを圧縮して得られる圧縮データを受信装置１２０に対して送信し、該値が閾値よりも小さい場合は、部分データを受信装置１２０に対して送信する。
【解決手段】 マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを受信装置１２０から受信する。マルチメディアデータから第１の記述により規定されている部分を部分データとして抽出する。第２の記述により規定されている方式に対応する係数を取得する。取得した係数に応じた値が閾値よりも大きい場合、部分データを圧縮して得られる圧縮データを受信装置１２０に対して送信し、該値が閾値よりも小さい場合は、部分データを受信装置１２０に対して送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアデータの送信技術に関するものである。
【背景技術】
【０００２】
従来、ＩＥＴＦで公開されているＲＦＣ３９８６の仕様では、ネットワーク上のファイルなどのリソースを識別するためのＵＲＩという記述方法が定義されている。この仕様に従うと、ＵＲＩの利用者は、ＵＲＩの一部にフラグメント識別子とよばれる記述を付加することによって、主リソースのデータの一部など副次的リソースを表現することができる。
【０００３】
さらに、Ｗ３Ｃでは、フラグメント識別子を使用して、動画などのマルチメディアデータを時間・座標・トラック種別（画像、音声、字幕など）で分割したデータを表現するメディアフラグメントＵＲＩの仕様を策定中である。
【０００４】
この仕様により、特許文献１で記載されているような動画の再生端末装置が、動画配信装置から動画を取得する際に、フラグメント識別子を含むＵＲＩを使用して、動画の一部を取得対象として指定することができる。
【０００５】
また、取得対象のリソースがＷｅｂサーバ上にあった場合、通信プロトコルとしてＲＦＣ２０６８で仕様が公開されているＨＴＴＰ／１．１が使われることが多い。ＨＴＴＰ／１．１では、ＨＴＴＰ圧縮エンコーディング方式が定義されており、圧縮効果のあるリソースを圧縮してデータサイズを小さくし、ネットワーク負荷を抑制することができる。なお、ＨＴＴＰ圧縮エンコーディング形式では、deflate, compress, gzipなどの圧縮方式を使用することが仕様で定義されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２０４００１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
動画データを保持するＷｅｂサーバと、動画データを利用するネットワーク端末と、で構成されるＷｅｂシステムで、端末側で字幕トラックなど動画の一部のデータだけを利用する場合がある。
【０００８】
例えば、Ｗｅｂサーバ上の複数の動画のうち、字幕に特定のキーワードが含まれる動画を端末側で選択、もしくは選択対象から除外したり、各動画の字幕の最初の部分を見出しとして利用者に提示したりする用途が考えられる。
【０００９】
これらの用途を実現する簡単な方式として、端末がＷｅｂサーバから全動画データを取得したあと、各動画データの形式に対応したスプリッタと呼ばれるアプリケーションで字幕トラックなど必要な部分を分離する方法が考えられる。
【００１０】
しかしながら、端末が小型機器である場合など、動画データ全体を保存するためのストレージ容量や、スプリッタを複数動作させる演算能力等のリソースが少ない場合に、上記用途を実現する際の処理速度が遅くなるという問題がある。
【００１１】
一方、Ｗｅｂサーバは、端末に比べてリソースに余裕がある場合が多いため、端末が動画の部分データをＷｅｂサーバに要求し、Ｗｅｂサーバ側でデータを分割する方式を採用すれば、上記のような処理速度の問題を解決することができる。この方式を実施する場合、端末が、必要なデータの範囲をメディアフラグメントＵＲＩのような記述方法でＷｅｂサーバに通知し、Ｗｅｂサーバから該当する部分データを取得する処理フローになる。この処理フローでは、端末から要求された部分データは、分割前の動画データと同じメディアタイプのデータとしてＷｅｂサーバから送信される。
【００１２】
一般に、動画データはすでに圧縮された形式となっているため、送信時の圧縮効果は少なく、動画データのメディアタイプをもつデータは、ＨＴＴＰ圧縮なしで送信される。ところが、ＭＰＥＧ−４ファイル形式など多くの動画データは、複数のトラックから構成されるコンテナ形式となっており、トラック種別で分割した場合、圧縮効果がある部分データとなる場合がある。
【００１３】
それにも関わらず、部分データをＷｅｂサーバから送信する場合、圧縮効果があるにも関わらず無圧縮で送信してしまうため、ネットワーク負荷を削減できないという問題があった。
【００１４】
本発明は以上の問題に鑑みてなされたものであり、外部の装置に格納されているコンテナ形式のリソースの部分データを、部分データに適した圧縮形式で取得する為の技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の目的を達成するために、例えば、本発明の送信装置は以下の構成を備える。即ち、外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段と、前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する手段と、前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する手段と、前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得手段と、前記取得手段が取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信手段とを備えることを特徴とする。
【発明の効果】
【００１６】
本発明の構成によれば、外部の装置に格納されているコンテナ形式のリソースの部分データを、部分データに適した圧縮形式で取得することができる。
【図面の簡単な説明】
【００１７】
【図１】システムの機能構成例を示すブロック図。
【図２】データ受信装置１２０及びデータ送信装置１００が行う処理のフローチャート。
【図３】コーデックの種別と圧縮方式との対応関係を示す図。
【図４】ＵＲＩをＷ３ＣのメディアフラグメントＵＲＩ形式で記述した４つの例を示す図。
【図５】要求メッセージ、応答メッセージの構成例を示す図。
【図６】分割方式と係数との対応関係を示す図。
【図７】コーデックの種別と優先圧縮方式とＨＴＴＰ標準の圧縮方式との対応関係を示す図。
【図８】要求メッセージ、応答メッセージの構成例を示す図。
【図９】システムの機能構成例を示すブロック図。
【図１０】データ受信装置１２０及びデータ送信装置１００が行う処理のフローチャート。
【図１１】圧縮レベル対応表の例を示す図。
【発明を実施するための形態】
【００１８】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載の構成の具体的な実施例の１つである。
【００１９】
［第１の実施形態］
先ず、本実施形態に係る送信装置を含むシステムについて、図１のブロック図を用いて説明する。データ送信装置１００及びデータ受信装置１２０はＬＡＮやインターネット等のネットワークに接続されており、このネットワークを介して互いにデータ通信が可能な構成となっている。更にデータ送信装置１００には、マルチメディアデータの一例としての動画像データ１３１を保持するデータ記憶装置１３０が接続されている。なお、図１ではデータ記憶装置１３０はデータ送信装置１００とは別個の装置としているが、データ送信装置１００と一体化させても良い。また、本実施形態ではマルチメディアデータの一例として動画像データ１３１を用いるが、音声データなど、他のデータをマルチメディアデータとして扱っても良い。
【００２０】
次に、データ送信装置１００について説明する。ＣＰＵ１１０は、データ送信装置１００全体の動作制御を行う。メモリ１１１は、ＣＰＵ１１０が各種の処理を実行する際に用いるワークエリアなど、様々なエリアを適宜提供することができるものである。
【００２１】
図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部は、ハードウェアで構成しても良いし、ソフトウェア（コンピュータプログラム）で構成しても良い。ソフトウェアで構成する場合、これらのソフトウェアは、データ送信装置１００内の不図示のメモリ内に格納され、ＣＰＵ１１０はこれらのソフトウェアを適宜メモリ１１１に読み出して実行する。なお、図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部の動作については、図２のフローチャートを用いて説明する。
【００２２】
データ受信装置１２０及びデータ送信装置１００が行う処理について、図２のフローチャートを用いて説明する。なお、以下の説明では、図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部を動作の主体としているが、これら各部をソフトウェアで構成する場合はこのソフトウェアはＣＰＵ１１０により実行される。然るにこの場合、主体はＣＰＵ１１０となる。もちろん、これら各部をハードウェアで構成する場合は、これら各部を主体としても良い。
【００２３】
ステップＳ２０１ではデータ受信装置１２０は、動画像データ１３１から部分的なデータ（部分データ）の取得要求を示す要求メッセージを作成し、上記のネットワークを介してデータ送信装置１００に対して送信する。例えば、データ受信装置１２０側の表示画面上にＷｅｂブラウザを表示し、このＷｅｂブラウザ上にこの部分データのＵＲＩを入力して送信指示を入力する。
【００２４】
ここで、部分データのＵＲＩをＷ３ＣのメディアフラグメントＵＲＩ形式で記述した４つの例を図４に示す。何れのＵＲＩも、「www.example.com」上にある動画像（ファイル名「example.mp4」）から抽出する部分を規定する第１の記述、この部分を抽出する方式を規定する第２の記述、を含む。
【００２５】
ＵＲＩ４０１は、この動画像において、再生開始時刻を０秒としたときに再生時刻10秒から20秒の間の部分を抽出対象として規定すると共に、この部分を動画像から抽出する方式としてtemporal分割方式を使用することを規定する。
【００２６】
ＵＲＩ４０２は、動画像において（ｘ、ｙ）＝（５０，８０）を起点とし幅３２０画素、高さ２４０画素のサイズの領域を抽出対象として規定すると共に、この領域を動画像から抽出する方式としてspatial分割方式を使用することを規定するものである。
【００２７】
ＵＲＩ４０３は、動画像において字幕トラック部分を抽出対象として規定すると共に、この字幕トラック部分を動画像から抽出する方式としてtrack分割方式を使用することを規定する。
【００２８】
ＵＲＩ４０４は、動画像において再生開始時刻を０秒としたときに再生時刻10秒から20秒の間の部分を抽出対象として規定すると共に、この部分を動画像から抽出する方式としてtemporal分割方式及びtrack分割方式を使用することを規定する。
【００２９】
ここで、ＵＲＩ４０３で表されるメディアフラグメントＵＲＩを、ＨＴＴＰプロトコルで要求する場合の、要求メッセージの構成例を図５（ａ）に示す。この要求メッセージでは、「www.example.com」上にある動画像（ファイル名「example.mp4」）において字幕トラックの部分がHTTP 1.1のGETメソッドで要求されていることが記述されている。また、この要求メッセージには、deflate方式で圧縮されたデータの受信が可能であることが記述されている。
【００３０】
図２に戻って、ステップＳ２０２では要求メッセージ受付部１０１は、データ受信装置１２０（外部装置）から送信された要求メッセージを受信する。ステップＳ２０３ではデータ分割方式取得部１０２は、ステップＳ２０２で取得した要求メッセージ中に記述されているデータの分割方式を参照する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、HTTPのRangeヘッダの値に”track=subtitle”という記述がある。そのため、データ分割方式取得部１０２は、この記述を参照し、メディアフラグメントＵＲＩの仕様により、データの分割方式は”track”であると判断する。
【００３１】
ステップＳ２０４ではデータ分割部１０３は、ステップＳ２０２で取得した要求メッセージ中に記述されているマルチメディアデータのファイル名を参照し、このファイル名を有するマルチメディアデータをデータ記憶装置１３０から読み出す。
【００３２】
例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、マルチメディアデータのファイル名として「example.mp4」が記されているため、このファイル名を有するマルチメディアデータをデータ記憶装置１３０から読み出す。以下では、ファイル名が「example.mp4」であるマルチメディアデータが動画像データ１３１であるものとして説明する。
【００３３】
次にデータ分割部１０３は、要求メッセージ中に抽出対象として規定されている部分を、この読み出した動画像データ１３１から、部分データとして抽出（分割）する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、ステップＳ２０３では分割方式が”track”であると判断するので、動画像データ１３１から字幕トラック部分を部分データとして抽出する。
【００３４】
なお、動画像データ１３１から部分データを抽出（分割）する技術は、スプリッタとよばれるプログラム等、各動画形式の一般的な動画デコーダに含まれる機能ですでに実現されているため、これに係る詳細な説明は省略する。
【００３５】
ステップＳ２０５では圧縮有効性判断部１０４は、ステップＳ２０４で抽出した部分データが圧縮効果のある分割方式により得られたものであるのか否か（圧縮の有効性があるか否か）を判断するための指標となる値としてデータ分割方式の圧縮有効度を求める。
【００３６】
本実施形態では、圧縮有効性判断部１０４は、図６に示す如く、分割方式毎に、該分割方式により抽出されるデータに対する圧縮の有効度を示す係数が登録されたテーブルを保持している。
【００３７】
図６において欄６０１には、temporal、spatial、track等の分割方式名が列挙されている。欄６０２には、欄６０１に列挙されたそれぞれの分割方式に対応する係数の値が列挙されている。例えば、分割方式「temporal」に対応する係数の値は「０」となっている。
【００３８】
然るにステップＳ２０５では圧縮有効性判断部１０４は、ステップＳ２０３で参照した全て（２つ以上）の分割方式について、対応する係数を図６のテーブルから取得する。その後、取得したそれぞれの係数と、各分割方式の使用有無を表すブール値の積と、の総和（Σ）を上記のデータ分割方式の圧縮有効度として計算する。ここで、ブール値は、使用していたら１、使用していなかったら０とする。例えば、図４のＵＲＩ４０４がメディアフラグメントＵＲＩとして記述されていた場合、以下の計算式により、データ分割方式の圧縮有効度は１となる。
データ分割方式の圧縮有効度
＝Σ（（分割方式の係数）×（分割方式の使用有無を表すブール値））
＝（temporal分割方式の係数）×（temporal分割方式の使用有無を表すブール値）
＋（spatial分割方式の係数）×（spatial分割方式の使用有無を表すブール値）
＋（track分割方式の係数）×（track分割方式の使用有無を表すブール値）
＝０×１＋０×０＋１×１＝１
【００３９】
そしてステップＳ２０６では圧縮有効性判断部１０４は、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値よりも大きいか否かを判断する。ここでは閾値＝０としている。そしてこの判断の結果、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値よりも大きい場合、ステップＳ２０４で抽出した部分データが、圧縮効果のある分割方式により得られたものであると判断し、処理をステップＳ２０７に進める。一方、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値以下の場合、ステップＳ２０４で抽出した部分データが、圧縮効果がない分割方式により得られたものであると判断し、処理をステップＳ２１２に進める。
【００４０】
ステップＳ２０７ではコーデック種別取得部１０５は、ステップＳ２０４で抽出した部分データのコーデックの種別を取得する。本実施形態では、動画像データ１３１に含まれるFourCCとよばれるコーデックの識別子を参照して、部分データのコーデックの種別を判断するが、動画像データ１３１の形式によっては、他の方法で判断してもよい。
【００４１】
例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、この要求メッセージには、動画像データ１３１であるexample.mp4内で字幕トラック部分のFourCC識別子が”tx3g”と記述されている。そのため、コーデック種別取得部１０５は、この部分を参照し、字幕トラック部分のコーデック種別が、3GPP Timed Text形式であると判断する。
【００４２】
ステップＳ２０８では圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式を決定する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、圧縮方式選択部１０６は、この要求メッセージのHTTPヘッダであるAccept-Encodingの値（第３の記述）を参照する。そして圧縮方式選択部１０６は、データ受信装置１２０はdeflate圧縮方式に対応可能であると判断する。
【００４３】
なお、要求メッセージ内にデータ受信装置１２０が対応可能な圧縮方式が記されていれば、処理はステップＳ２０９を介してステップＳ２１０に進み、記されていなければ、処理はステップＳ２０９を介してステップＳ２１２に進む。
【００４４】
ステップＳ２１０で圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式のうち、ステップＳ２０７で取得したコーデックの種別（識別子）に適した圧縮方式を選択する。圧縮方式選択部１０６は、図３に示す如く、コーデックの種別毎に、それに適した圧縮方式が登録されたテーブルを保持している。なお、図３では、コーデック種別の値として前述のFourCC識別子、圧縮方式の値として、HTTPプロトコルのAccept-Encodingで指定可能なdeflate, gzip, identity（無圧縮）を使用している。
【００４５】
図３において欄３０１には様々なコーデックの種別（識別子）が登録されており、欄３０２には、それぞれのコーデックの種別に適した圧縮方式が登録されている。例えば、図３のテーブルによれば、コーデックの種別が「ｔｘ３ｇ」であれば、それに適した圧縮方式（予め設定された）は「deflate」若しくは「gzip」となる。然るに圧縮方式選択部１０６は、図３のテーブルを参照し、ステップＳ２０７で取得したコーデックの種別に対応する圧縮方式のうち、データ受信装置１２０が対応可能な圧縮方式を選択する。即ち、ステップＳ２０７で取得したコーデックの種別に対応する圧縮方式と、データ受信装置１２０が対応可能な圧縮方式と、で共通の圧縮方式を選択する。
【００４６】
例えばステップＳ２０２で図５（ａ）の要求メッセージを受信した場合、字幕トラック部分のコーデックの種別が”tx3g”であるので、圧縮方式選択部１０６は図３のテーブルより”tx3g”に対応する圧縮方式deflate、gzipを選択する。次に圧縮方式選択部１０６は、データ受信装置１２０がdeflate方式に対応していることから、選択した圧縮方式「deflate」、「gzip」のうち圧縮方式「deflate」を送信時の圧縮方式として選択する。
【００４７】
ステップＳ２１１で圧縮実行部１０７は、ステップＳ２１０で送信時の圧縮方式として選択した圧縮方式に従って、ステップＳ２０４で抽出した部分データを圧縮し、圧縮データを生成する。
【００４８】
ステップＳ２１２では応答メッセージ生成部１０８は、応答メッセージを生成する。ステップＳ２１１からステップＳ２１２に処理が進んだ場合、ステップＳ２１２では、図５（ｂ）に示す如く、ステップＳ２１１で生成した圧縮データを含む、HTTPプロトコル用の応答メッセージを生成する。
【００４９】
ここで、Content-Range-Mappingヘッダは、メディアフラグメントＵＲＩの仕様で提案されているヘッダであり、応答メッセージに含まれるデータが、track分割方式で分割された動画像データ１３１の一部であることを示す。また、Content-Encodingヘッダは、HTTP圧縮がdeflate方式で行われたことを示す。また、Content-Typeヘッダは、分割前の動画像データ１３１のメディアタイプであるvideo／mp4が記述されている。
【００５０】
一方、ステップＳ２０６若しくはステップＳ２０９からステップＳ２１２に処理が進んだ場合、ステップＳ２１２では、ステップＳ２０４で抽出した部分データを含む応答メッセージを生成する。
【００５１】
ここで、部分データのメディアタイプは、動画像データ１３１と同じとは限らないため、あらかじめ送信側と受信側で、どのメディアタイプを使用するかを制限しておく方法や、他のヘッダ情報で通知する方法などが考えられる。
【００５２】
ステップＳ２１３では応答メッセージ送信部１０９は、ステップＳ２１２で生成した応答メッセージをデータ受信装置１２０に対して送信する。ステップＳ２１４ではデータ受信装置１２０は、データ送信装置１００から送信された応答メッセージを受信する。
【００５３】
そしてステップＳ２１５ではデータ受信装置１２０は、この受信した応答メッセージ中の部分データが圧縮されているか否かを判断する。この判断の結果、部分データが圧縮されている場合、処理はステップＳ２１６に進み、圧縮されていない場合、処理はステップＳ２１７に進む。
【００５４】
ステップＳ２１６ではデータ受信装置１２０は、圧縮されている部分データを伸張する。ステップＳ２１７ではデータ受信装置１２０は、応答メッセージ中に含まれている部分データ若しくはステップＳ２１６で伸張した部分データを適当なメモリに格納したり、適当な表示装置上に表示したりすることで、データ送信装置１００に要求した情報を得る。
【００５５】
以上の説明により、本実施形態によれば、Ｗｅｂサーバ等の装置上にある動画像データ等のコンテナ形式のリソースの部分データを取得する場合、部分データに適した圧縮形式で取得することができる。
【００５６】
特に、部分データが、動画像データにおける字幕トラック部分の形式であるＳＲＴ形式や３ＧＰＰ Ｔｉｍｅｄ Ｔｅｘｔ形式などテキストで記述されていた場合、圧縮効果が大きくなる。これにより、ネットワークで送信するデータ量が小さくなるため、ネットワークトラフィックを抑制することができる。
【００５７】
［第２の実施形態］
第１の実施形態では、ＨＴＴＰで定義された圧縮送信方式を用いた例について説明したが、本実施形態では、W3C EXI形式、ISO Fast Infoset形式などのバイナリXML形式に対応していた場合について説明する。なお、本実施形態においても、システム全体の構成については第１の実施形態と同じ（図１）である。以下では、第１の実施形態との相違点のみについて説明する。
【００５８】
バイナリXML形式は、XML形式のデータを圧縮する技術で、この形式に対応したXMLパーサがあった場合、圧縮したまま解析することができる。そのため、図２のステップＳ２１５、Ｓ２１６のデータ伸長に係る処理が不要となる。これにより、データ受信装置１２０側のデータ伸長時の計算時間が減り、データ取得の処理全体が高速化する効果がある。
【００５９】
なお、本実施形態では更に、図２のフローチャートにおいて、ステップＳ２０８、Ｓ２１０で説明した圧縮方式の選択に係る処理が第１の実施形態と異なる。
【００６０】
ステップＳ２０８では圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式を、第１の実施形態と同様に、要求メッセージのHTTPヘッダであるAccept-Encodingの値を参照して決定する。
【００６１】
ここで、データ受信装置１２０がEXI, Fast Infoset形式の圧縮に対応している場合に、要求メッセージ受付部１０１がＨＴＴＰプロトコルで受信した要求メッセージの一例を図８（ａ）に示す。
【００６２】
図８（ａ）では、Accept-Encoding値として、exi, finf, deflateが記述されている。この記述は、データ受信装置１２０が、W3C EXI, ISO Fast Infoset, deflate方式に対応していることを示している。
【００６３】
ステップＳ２１０で圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式のうち、ステップＳ２０７で取得したコーデックの種別（識別子）に適した圧縮方式を選択する。圧縮方式選択部１０６は、図７に示す如く、コーデックの種別毎に、それに適した圧縮方式（優先圧縮方式）とＨＴＴＰ標準の圧縮方式と、が登録されたテーブルを保持している。
【００６４】
なお、図７では、コーデック種別の値として前述のFourCC識別子、通常圧縮方式の値として、deflate, gzip, identity（無圧縮）を使用している他、優先圧縮方式として、exi(W3C EXI形式)が定義されている。
【００６５】
図７において欄７０１には様々なコーデックの種別（識別子）が登録されており、欄７０２にはそれぞれのコーデックの種別に適した圧縮方式が登録されており、欄７０３にはそれぞれのコーデックの種別に対応するＨＴＴＰ標準の圧縮方式が登録されている。例えば、図７のテーブルによれば、コーデックの種別が「ｔｘ３ｇ」であれば、それに適した圧縮方式は「exi」となり、ＨＴＴＰ標準の圧縮方式は「deflate」、「gzip」となる。然るに圧縮方式選択部１０６は、図７のテーブルを参照し、先ず、ステップＳ２０７で取得したコーデックの種別に対応する優先圧縮方式を選択する。そして、選択した優先圧縮方式がデータ受信装置１２０が対応可能な圧縮方式であれば、この優先圧縮方式を送信時の圧縮方式として選択する。一方、対応可能な圧縮方式でなければ、ステップＳ２０７で取得したコーデックの種別に対応する通常圧縮方式を、送信時の圧縮方式として選択する。
【００６６】
例えばステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、字幕トラック部分のコーデックの種別が”tx3g”であることから、圧縮方式選択部１０６は図７のテーブルより先ず、”tx3g”に対応する圧縮方式「exi」を選択する。次に圧縮方式選択部１０６は、データ受信装置１２０がexi方式に対応していることから、選択した圧縮方式「exi」を送信時の圧縮方式として選択する。この場合に、応答メッセージ生成部１０８により生成される応答メッセージの構成例を図８（ｂ）に示す。
【００６７】
ここで、Content-Range-Mappingヘッダは、メディアフラグメントＵＲＩの仕様で提案されているヘッダであり、応答メッセージに含まれるデータが、track分割方式で分割された動画像データ１３１の一部であることを示す。
【００６８】
また、X-Content-Encodingヘッダは、HTTP圧縮がexi方式で行われたことを示す。通常のHTTP圧縮では、exi方式を記述できないため、HTTPのContent-Encodingヘッダを拡張したヘッダとして記述している。
【００６９】
［第３の実施形態］
第１の実施形態では、分割したデータを圧縮するかどうかの判断を、圧縮効果がある分割方式（第１の実施形態では、track分割方式）の使用の有無から判断した。本実施形態では、図４のＵＲＩ４０４のように、複数の分割方式が指定された場合に、圧縮効果のある分割方式の使用の有無だけでなく、圧縮対象となるデータの範囲（圧縮影響範囲）と合わせて、圧縮するかどうかを判断することを特徴とする。これにより、分割したデータのサイズが小さく、圧縮による送信データのサイズ縮小の効果が少ない場合はデータ圧縮せず、送信側・受信側のデータ圧縮・伸長処理によるＣＰＵ負荷や送信時間の遅延を低減する効果を得る。
【００７０】
先ず、本実施形態に係る送信装置を含むシステムの機能構成例について、図９のブロック図を用いて説明する。図９の１００から１３１については、図１と同じであるため説明を省略する。本実施形態では、圧縮影響範囲を取得する圧縮影響範囲取得部９０１が追加されている点が図１と異なる。
【００７１】
図１０は、本実施形態に係る送信装置が行う処理のフローチャートである。ステップＳ２０１〜Ｓ２０４、ステップＳ２０７〜Ｓ２１７の処理については、図２と同じであるため説明を省略する。
【００７２】
データ分割部１０３がステップＳ２０４において部分データを生成した後、ステップＳ１００１では、圧縮影響範囲取得部９０１が、圧縮影響範囲の値を算出する。なお、本実施形態では、圧縮影響範囲として、分割後のデータサイズの予測値を使用する。分割後のデータサイズは、分割前のデータサイズと各分割形式によるサイズ縮小率の総積（Π）から以下の計算式で求める。
【００７３】
圧縮影響範囲＝（分割前のデータサイズ）×Π（各分割方式によるデータサイズ縮小率）
＝（分割前のデータサイズ）×（temporal分割方式によるデータサイズ縮小率）×（spatial分割方式によるデータサイズ縮小率）×（track分割方式によるデータサイズ縮小率）
【００７４】
また、本実施形態では、各分割方式による縮小率は、以下の計算式で求める。
【００７５】
temporal分割方式によるデータサイズ縮小率＝（分割後の再生時間）÷（分割前の再生時間）
spatial分割方式によるデータサイズ縮小率＝（分割後の画素数）÷（分割前の画素数）
track分割方式によるデータサイズ縮小率＝（分割後のトラック数）÷（分割前のトラック数）
【００７６】
ここで、分割前のデータ(example.mp4)のデータサイズが100MB、再生時間が1800秒、トラック数が3個、画素数が640×360ピクセルだったとする。この場合、図４のＵＲＩ４０４に記述されるメディアフラグメントＵＲＩが指定された時の圧縮影響範囲は、以下のとおりとなる。
【００７７】
圧縮影響範囲＝100MB×{(20−10)÷1800}×{(640×360)÷(640×360)}×{1／3}
＝0.19MB
【００７８】
次に、ステップＳ１００２では、圧縮有効性判断部１０４が、第１の実施形態で説明したデータ分割方式の圧縮有効度と、圧縮影響範囲から圧縮の有効性を示す圧縮有効度と、を算出する。本実施形態では、「圧縮影響範囲から圧縮の有効性を示す圧縮有効度」は、以下の計算式で算出する。
【００７９】
圧縮有効度＝（データ分割方式の圧縮有効度）×（圧縮影響範囲）＝ １×0.19 = 0.19MB
【００８０】
なお、データ分割方式の圧縮有効度についての説明は、第１の実施形態で行ったため、ここでは省略する。
【００８１】
次に、ステップＳ１００３では、圧縮有効性判断部１０４は、送信装置にあらかじめ設定してあった圧縮有効度の閾値を参照し、圧縮有効度が閾値より大きかったら圧縮が有効と判断し、処理はステップＳ２０７に進む。一方、閾値以下だったら、圧縮が無効と判断し、処理はステップＳ２１２に進む。たとえば、圧縮有効度が0.19MBで閾値が1MBであった場合、分割後のデータは圧縮されずに、処理はステップＳ２１２に進むことになる。なお、その後の処理については、第１の実施形態と同じであるため、説明を省略する。
【００８２】
なお、本実施形態では、データサイズ縮小率を算出する際、動画像の圧縮率が全時刻で一様かつ、全領域で一様かつ、全トラックで一様と仮定し、分割範囲とデータサイズに比例関係が成立するとして計算した。しかし、動画像の詳細な縮小率が取得できる場合、その値を用いて計算してもよい。例えば、特定の時刻の縮小率がPtemp(t)、特定の領域の縮小率がPs(x, y, w, h, t)、特定のトラックの縮小率がPtr(tr, t)だったとする。この場合、圧縮影響範囲は以下の計算式から求めることができる。
【００８３】
圧縮影響範囲
＝分割前のデータサイズ×∫t=tst=tePtemp(t)Ps(x, y, w, h, t)Ptr(tr, t)dt
【００８４】
ここで、t: 特定の時刻を表す変数、ts:部分データの開始時刻、te:部分データの終了時刻、x:部分データのx座標、y:部分データのy座標、w:部分データの幅、h:部分データの高さ、tr:部分データのトラック種別である。
【００８５】
［第４の実施形態］
Deflateなどのデータ圧縮アルゴリズムでは、圧縮時に圧縮レベルを設定することが可能である。一般に、圧縮レベルが高い場合は、圧縮率は高くなるが、圧縮処理時間が長くなるという傾向がある。
【００８６】
第３の実施形態では、ステップＳ１００３の処理において圧縮有効性判断部１０４は、分割結果のデータを圧縮するかどうかを1つの閾値で判断した。本実施形態では、圧縮有効性判断部１０４は、複数の閾値を使用し、圧縮をするかどうかだけでなく、圧縮する際に指定する圧縮レベルを判断する。これにより、圧縮実行部１０７が、圧縮方式選択部１０６が選択した圧縮方式にしたがって分割データを圧縮する際に、分割データに合わせた圧縮レベルで圧縮処理を行うことができる。すなわち、分割後のデータのサイズが大きい場合には圧縮率を重視した圧縮レベルを使用してデータサイズを小さくすることで通信負荷を下げ、小さい場合には圧縮時間を重視した圧縮レベルを使用することができる。
【００８７】
図１１は、複数の閾値と圧縮レベルとを対応づけた圧縮レベル対応表の例である。圧縮有効度欄１１０１には、それぞれの圧縮有効度に対する閾値が記述されている。圧縮レベル欄１１０２には、各閾値に対応する圧縮レベルが記述されている。圧縮有効性判断部１０４は、ステップＳ１００３の処理でこの圧縮レベル対応表を参照し、例えば、圧縮有効度が1MB未満のときは圧縮が無効と判断する。また、10MB未満のとき圧縮レベル4を使用すると判断する。さらに10MB以上のとき、圧縮レベル9を使用すると判断する。なお、この圧縮レベル対応表は、メモリ１１１内に保持されているものとする。
【００８８】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【技術分野】
【０００１】
本発明は、マルチメディアデータの送信技術に関するものである。
【背景技術】
【０００２】
従来、ＩＥＴＦで公開されているＲＦＣ３９８６の仕様では、ネットワーク上のファイルなどのリソースを識別するためのＵＲＩという記述方法が定義されている。この仕様に従うと、ＵＲＩの利用者は、ＵＲＩの一部にフラグメント識別子とよばれる記述を付加することによって、主リソースのデータの一部など副次的リソースを表現することができる。
【０００３】
さらに、Ｗ３Ｃでは、フラグメント識別子を使用して、動画などのマルチメディアデータを時間・座標・トラック種別（画像、音声、字幕など）で分割したデータを表現するメディアフラグメントＵＲＩの仕様を策定中である。
【０００４】
この仕様により、特許文献１で記載されているような動画の再生端末装置が、動画配信装置から動画を取得する際に、フラグメント識別子を含むＵＲＩを使用して、動画の一部を取得対象として指定することができる。
【０００５】
また、取得対象のリソースがＷｅｂサーバ上にあった場合、通信プロトコルとしてＲＦＣ２０６８で仕様が公開されているＨＴＴＰ／１．１が使われることが多い。ＨＴＴＰ／１．１では、ＨＴＴＰ圧縮エンコーディング方式が定義されており、圧縮効果のあるリソースを圧縮してデータサイズを小さくし、ネットワーク負荷を抑制することができる。なお、ＨＴＴＰ圧縮エンコーディング形式では、deflate, compress, gzipなどの圧縮方式を使用することが仕様で定義されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２０４００１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
動画データを保持するＷｅｂサーバと、動画データを利用するネットワーク端末と、で構成されるＷｅｂシステムで、端末側で字幕トラックなど動画の一部のデータだけを利用する場合がある。
【０００８】
例えば、Ｗｅｂサーバ上の複数の動画のうち、字幕に特定のキーワードが含まれる動画を端末側で選択、もしくは選択対象から除外したり、各動画の字幕の最初の部分を見出しとして利用者に提示したりする用途が考えられる。
【０００９】
これらの用途を実現する簡単な方式として、端末がＷｅｂサーバから全動画データを取得したあと、各動画データの形式に対応したスプリッタと呼ばれるアプリケーションで字幕トラックなど必要な部分を分離する方法が考えられる。
【００１０】
しかしながら、端末が小型機器である場合など、動画データ全体を保存するためのストレージ容量や、スプリッタを複数動作させる演算能力等のリソースが少ない場合に、上記用途を実現する際の処理速度が遅くなるという問題がある。
【００１１】
一方、Ｗｅｂサーバは、端末に比べてリソースに余裕がある場合が多いため、端末が動画の部分データをＷｅｂサーバに要求し、Ｗｅｂサーバ側でデータを分割する方式を採用すれば、上記のような処理速度の問題を解決することができる。この方式を実施する場合、端末が、必要なデータの範囲をメディアフラグメントＵＲＩのような記述方法でＷｅｂサーバに通知し、Ｗｅｂサーバから該当する部分データを取得する処理フローになる。この処理フローでは、端末から要求された部分データは、分割前の動画データと同じメディアタイプのデータとしてＷｅｂサーバから送信される。
【００１２】
一般に、動画データはすでに圧縮された形式となっているため、送信時の圧縮効果は少なく、動画データのメディアタイプをもつデータは、ＨＴＴＰ圧縮なしで送信される。ところが、ＭＰＥＧ−４ファイル形式など多くの動画データは、複数のトラックから構成されるコンテナ形式となっており、トラック種別で分割した場合、圧縮効果がある部分データとなる場合がある。
【００１３】
それにも関わらず、部分データをＷｅｂサーバから送信する場合、圧縮効果があるにも関わらず無圧縮で送信してしまうため、ネットワーク負荷を削減できないという問題があった。
【００１４】
本発明は以上の問題に鑑みてなされたものであり、外部の装置に格納されているコンテナ形式のリソースの部分データを、部分データに適した圧縮形式で取得する為の技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の目的を達成するために、例えば、本発明の送信装置は以下の構成を備える。即ち、外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段と、前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する手段と、前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する手段と、前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得手段と、前記取得手段が取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信手段とを備えることを特徴とする。
【発明の効果】
【００１６】
本発明の構成によれば、外部の装置に格納されているコンテナ形式のリソースの部分データを、部分データに適した圧縮形式で取得することができる。
【図面の簡単な説明】
【００１７】
【図１】システムの機能構成例を示すブロック図。
【図２】データ受信装置１２０及びデータ送信装置１００が行う処理のフローチャート。
【図３】コーデックの種別と圧縮方式との対応関係を示す図。
【図４】ＵＲＩをＷ３ＣのメディアフラグメントＵＲＩ形式で記述した４つの例を示す図。
【図５】要求メッセージ、応答メッセージの構成例を示す図。
【図６】分割方式と係数との対応関係を示す図。
【図７】コーデックの種別と優先圧縮方式とＨＴＴＰ標準の圧縮方式との対応関係を示す図。
【図８】要求メッセージ、応答メッセージの構成例を示す図。
【図９】システムの機能構成例を示すブロック図。
【図１０】データ受信装置１２０及びデータ送信装置１００が行う処理のフローチャート。
【図１１】圧縮レベル対応表の例を示す図。
【発明を実施するための形態】
【００１８】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載の構成の具体的な実施例の１つである。
【００１９】
［第１の実施形態］
先ず、本実施形態に係る送信装置を含むシステムについて、図１のブロック図を用いて説明する。データ送信装置１００及びデータ受信装置１２０はＬＡＮやインターネット等のネットワークに接続されており、このネットワークを介して互いにデータ通信が可能な構成となっている。更にデータ送信装置１００には、マルチメディアデータの一例としての動画像データ１３１を保持するデータ記憶装置１３０が接続されている。なお、図１ではデータ記憶装置１３０はデータ送信装置１００とは別個の装置としているが、データ送信装置１００と一体化させても良い。また、本実施形態ではマルチメディアデータの一例として動画像データ１３１を用いるが、音声データなど、他のデータをマルチメディアデータとして扱っても良い。
【００２０】
次に、データ送信装置１００について説明する。ＣＰＵ１１０は、データ送信装置１００全体の動作制御を行う。メモリ１１１は、ＣＰＵ１１０が各種の処理を実行する際に用いるワークエリアなど、様々なエリアを適宜提供することができるものである。
【００２１】
図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部は、ハードウェアで構成しても良いし、ソフトウェア（コンピュータプログラム）で構成しても良い。ソフトウェアで構成する場合、これらのソフトウェアは、データ送信装置１００内の不図示のメモリ内に格納され、ＣＰＵ１１０はこれらのソフトウェアを適宜メモリ１１１に読み出して実行する。なお、図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部の動作については、図２のフローチャートを用いて説明する。
【００２２】
データ受信装置１２０及びデータ送信装置１００が行う処理について、図２のフローチャートを用いて説明する。なお、以下の説明では、図１に示したデータ送信装置１００を構成する各部のうちＣＰＵ１１０及びメモリ１１１を除く各部を動作の主体としているが、これら各部をソフトウェアで構成する場合はこのソフトウェアはＣＰＵ１１０により実行される。然るにこの場合、主体はＣＰＵ１１０となる。もちろん、これら各部をハードウェアで構成する場合は、これら各部を主体としても良い。
【００２３】
ステップＳ２０１ではデータ受信装置１２０は、動画像データ１３１から部分的なデータ（部分データ）の取得要求を示す要求メッセージを作成し、上記のネットワークを介してデータ送信装置１００に対して送信する。例えば、データ受信装置１２０側の表示画面上にＷｅｂブラウザを表示し、このＷｅｂブラウザ上にこの部分データのＵＲＩを入力して送信指示を入力する。
【００２４】
ここで、部分データのＵＲＩをＷ３ＣのメディアフラグメントＵＲＩ形式で記述した４つの例を図４に示す。何れのＵＲＩも、「www.example.com」上にある動画像（ファイル名「example.mp4」）から抽出する部分を規定する第１の記述、この部分を抽出する方式を規定する第２の記述、を含む。
【００２５】
ＵＲＩ４０１は、この動画像において、再生開始時刻を０秒としたときに再生時刻10秒から20秒の間の部分を抽出対象として規定すると共に、この部分を動画像から抽出する方式としてtemporal分割方式を使用することを規定する。
【００２６】
ＵＲＩ４０２は、動画像において（ｘ、ｙ）＝（５０，８０）を起点とし幅３２０画素、高さ２４０画素のサイズの領域を抽出対象として規定すると共に、この領域を動画像から抽出する方式としてspatial分割方式を使用することを規定するものである。
【００２７】
ＵＲＩ４０３は、動画像において字幕トラック部分を抽出対象として規定すると共に、この字幕トラック部分を動画像から抽出する方式としてtrack分割方式を使用することを規定する。
【００２８】
ＵＲＩ４０４は、動画像において再生開始時刻を０秒としたときに再生時刻10秒から20秒の間の部分を抽出対象として規定すると共に、この部分を動画像から抽出する方式としてtemporal分割方式及びtrack分割方式を使用することを規定する。
【００２９】
ここで、ＵＲＩ４０３で表されるメディアフラグメントＵＲＩを、ＨＴＴＰプロトコルで要求する場合の、要求メッセージの構成例を図５（ａ）に示す。この要求メッセージでは、「www.example.com」上にある動画像（ファイル名「example.mp4」）において字幕トラックの部分がHTTP 1.1のGETメソッドで要求されていることが記述されている。また、この要求メッセージには、deflate方式で圧縮されたデータの受信が可能であることが記述されている。
【００３０】
図２に戻って、ステップＳ２０２では要求メッセージ受付部１０１は、データ受信装置１２０（外部装置）から送信された要求メッセージを受信する。ステップＳ２０３ではデータ分割方式取得部１０２は、ステップＳ２０２で取得した要求メッセージ中に記述されているデータの分割方式を参照する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、HTTPのRangeヘッダの値に”track=subtitle”という記述がある。そのため、データ分割方式取得部１０２は、この記述を参照し、メディアフラグメントＵＲＩの仕様により、データの分割方式は”track”であると判断する。
【００３１】
ステップＳ２０４ではデータ分割部１０３は、ステップＳ２０２で取得した要求メッセージ中に記述されているマルチメディアデータのファイル名を参照し、このファイル名を有するマルチメディアデータをデータ記憶装置１３０から読み出す。
【００３２】
例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、マルチメディアデータのファイル名として「example.mp4」が記されているため、このファイル名を有するマルチメディアデータをデータ記憶装置１３０から読み出す。以下では、ファイル名が「example.mp4」であるマルチメディアデータが動画像データ１３１であるものとして説明する。
【００３３】
次にデータ分割部１０３は、要求メッセージ中に抽出対象として規定されている部分を、この読み出した動画像データ１３１から、部分データとして抽出（分割）する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、ステップＳ２０３では分割方式が”track”であると判断するので、動画像データ１３１から字幕トラック部分を部分データとして抽出する。
【００３４】
なお、動画像データ１３１から部分データを抽出（分割）する技術は、スプリッタとよばれるプログラム等、各動画形式の一般的な動画デコーダに含まれる機能ですでに実現されているため、これに係る詳細な説明は省略する。
【００３５】
ステップＳ２０５では圧縮有効性判断部１０４は、ステップＳ２０４で抽出した部分データが圧縮効果のある分割方式により得られたものであるのか否か（圧縮の有効性があるか否か）を判断するための指標となる値としてデータ分割方式の圧縮有効度を求める。
【００３６】
本実施形態では、圧縮有効性判断部１０４は、図６に示す如く、分割方式毎に、該分割方式により抽出されるデータに対する圧縮の有効度を示す係数が登録されたテーブルを保持している。
【００３７】
図６において欄６０１には、temporal、spatial、track等の分割方式名が列挙されている。欄６０２には、欄６０１に列挙されたそれぞれの分割方式に対応する係数の値が列挙されている。例えば、分割方式「temporal」に対応する係数の値は「０」となっている。
【００３８】
然るにステップＳ２０５では圧縮有効性判断部１０４は、ステップＳ２０３で参照した全て（２つ以上）の分割方式について、対応する係数を図６のテーブルから取得する。その後、取得したそれぞれの係数と、各分割方式の使用有無を表すブール値の積と、の総和（Σ）を上記のデータ分割方式の圧縮有効度として計算する。ここで、ブール値は、使用していたら１、使用していなかったら０とする。例えば、図４のＵＲＩ４０４がメディアフラグメントＵＲＩとして記述されていた場合、以下の計算式により、データ分割方式の圧縮有効度は１となる。
データ分割方式の圧縮有効度
＝Σ（（分割方式の係数）×（分割方式の使用有無を表すブール値））
＝（temporal分割方式の係数）×（temporal分割方式の使用有無を表すブール値）
＋（spatial分割方式の係数）×（spatial分割方式の使用有無を表すブール値）
＋（track分割方式の係数）×（track分割方式の使用有無を表すブール値）
＝０×１＋０×０＋１×１＝１
【００３９】
そしてステップＳ２０６では圧縮有効性判断部１０４は、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値よりも大きいか否かを判断する。ここでは閾値＝０としている。そしてこの判断の結果、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値よりも大きい場合、ステップＳ２０４で抽出した部分データが、圧縮効果のある分割方式により得られたものであると判断し、処理をステップＳ２０７に進める。一方、ステップＳ２０５で求めたデータ分割方式の圧縮有効度が閾値以下の場合、ステップＳ２０４で抽出した部分データが、圧縮効果がない分割方式により得られたものであると判断し、処理をステップＳ２１２に進める。
【００４０】
ステップＳ２０７ではコーデック種別取得部１０５は、ステップＳ２０４で抽出した部分データのコーデックの種別を取得する。本実施形態では、動画像データ１３１に含まれるFourCCとよばれるコーデックの識別子を参照して、部分データのコーデックの種別を判断するが、動画像データ１３１の形式によっては、他の方法で判断してもよい。
【００４１】
例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、この要求メッセージには、動画像データ１３１であるexample.mp4内で字幕トラック部分のFourCC識別子が”tx3g”と記述されている。そのため、コーデック種別取得部１０５は、この部分を参照し、字幕トラック部分のコーデック種別が、3GPP Timed Text形式であると判断する。
【００４２】
ステップＳ２０８では圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式を決定する。例えば、ステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、圧縮方式選択部１０６は、この要求メッセージのHTTPヘッダであるAccept-Encodingの値（第３の記述）を参照する。そして圧縮方式選択部１０６は、データ受信装置１２０はdeflate圧縮方式に対応可能であると判断する。
【００４３】
なお、要求メッセージ内にデータ受信装置１２０が対応可能な圧縮方式が記されていれば、処理はステップＳ２０９を介してステップＳ２１０に進み、記されていなければ、処理はステップＳ２０９を介してステップＳ２１２に進む。
【００４４】
ステップＳ２１０で圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式のうち、ステップＳ２０７で取得したコーデックの種別（識別子）に適した圧縮方式を選択する。圧縮方式選択部１０６は、図３に示す如く、コーデックの種別毎に、それに適した圧縮方式が登録されたテーブルを保持している。なお、図３では、コーデック種別の値として前述のFourCC識別子、圧縮方式の値として、HTTPプロトコルのAccept-Encodingで指定可能なdeflate, gzip, identity（無圧縮）を使用している。
【００４５】
図３において欄３０１には様々なコーデックの種別（識別子）が登録されており、欄３０２には、それぞれのコーデックの種別に適した圧縮方式が登録されている。例えば、図３のテーブルによれば、コーデックの種別が「ｔｘ３ｇ」であれば、それに適した圧縮方式（予め設定された）は「deflate」若しくは「gzip」となる。然るに圧縮方式選択部１０６は、図３のテーブルを参照し、ステップＳ２０７で取得したコーデックの種別に対応する圧縮方式のうち、データ受信装置１２０が対応可能な圧縮方式を選択する。即ち、ステップＳ２０７で取得したコーデックの種別に対応する圧縮方式と、データ受信装置１２０が対応可能な圧縮方式と、で共通の圧縮方式を選択する。
【００４６】
例えばステップＳ２０２で図５（ａ）の要求メッセージを受信した場合、字幕トラック部分のコーデックの種別が”tx3g”であるので、圧縮方式選択部１０６は図３のテーブルより”tx3g”に対応する圧縮方式deflate、gzipを選択する。次に圧縮方式選択部１０６は、データ受信装置１２０がdeflate方式に対応していることから、選択した圧縮方式「deflate」、「gzip」のうち圧縮方式「deflate」を送信時の圧縮方式として選択する。
【００４７】
ステップＳ２１１で圧縮実行部１０７は、ステップＳ２１０で送信時の圧縮方式として選択した圧縮方式に従って、ステップＳ２０４で抽出した部分データを圧縮し、圧縮データを生成する。
【００４８】
ステップＳ２１２では応答メッセージ生成部１０８は、応答メッセージを生成する。ステップＳ２１１からステップＳ２１２に処理が進んだ場合、ステップＳ２１２では、図５（ｂ）に示す如く、ステップＳ２１１で生成した圧縮データを含む、HTTPプロトコル用の応答メッセージを生成する。
【００４９】
ここで、Content-Range-Mappingヘッダは、メディアフラグメントＵＲＩの仕様で提案されているヘッダであり、応答メッセージに含まれるデータが、track分割方式で分割された動画像データ１３１の一部であることを示す。また、Content-Encodingヘッダは、HTTP圧縮がdeflate方式で行われたことを示す。また、Content-Typeヘッダは、分割前の動画像データ１３１のメディアタイプであるvideo／mp4が記述されている。
【００５０】
一方、ステップＳ２０６若しくはステップＳ２０９からステップＳ２１２に処理が進んだ場合、ステップＳ２１２では、ステップＳ２０４で抽出した部分データを含む応答メッセージを生成する。
【００５１】
ここで、部分データのメディアタイプは、動画像データ１３１と同じとは限らないため、あらかじめ送信側と受信側で、どのメディアタイプを使用するかを制限しておく方法や、他のヘッダ情報で通知する方法などが考えられる。
【００５２】
ステップＳ２１３では応答メッセージ送信部１０９は、ステップＳ２１２で生成した応答メッセージをデータ受信装置１２０に対して送信する。ステップＳ２１４ではデータ受信装置１２０は、データ送信装置１００から送信された応答メッセージを受信する。
【００５３】
そしてステップＳ２１５ではデータ受信装置１２０は、この受信した応答メッセージ中の部分データが圧縮されているか否かを判断する。この判断の結果、部分データが圧縮されている場合、処理はステップＳ２１６に進み、圧縮されていない場合、処理はステップＳ２１７に進む。
【００５４】
ステップＳ２１６ではデータ受信装置１２０は、圧縮されている部分データを伸張する。ステップＳ２１７ではデータ受信装置１２０は、応答メッセージ中に含まれている部分データ若しくはステップＳ２１６で伸張した部分データを適当なメモリに格納したり、適当な表示装置上に表示したりすることで、データ送信装置１００に要求した情報を得る。
【００５５】
以上の説明により、本実施形態によれば、Ｗｅｂサーバ等の装置上にある動画像データ等のコンテナ形式のリソースの部分データを取得する場合、部分データに適した圧縮形式で取得することができる。
【００５６】
特に、部分データが、動画像データにおける字幕トラック部分の形式であるＳＲＴ形式や３ＧＰＰ Ｔｉｍｅｄ Ｔｅｘｔ形式などテキストで記述されていた場合、圧縮効果が大きくなる。これにより、ネットワークで送信するデータ量が小さくなるため、ネットワークトラフィックを抑制することができる。
【００５７】
［第２の実施形態］
第１の実施形態では、ＨＴＴＰで定義された圧縮送信方式を用いた例について説明したが、本実施形態では、W3C EXI形式、ISO Fast Infoset形式などのバイナリXML形式に対応していた場合について説明する。なお、本実施形態においても、システム全体の構成については第１の実施形態と同じ（図１）である。以下では、第１の実施形態との相違点のみについて説明する。
【００５８】
バイナリXML形式は、XML形式のデータを圧縮する技術で、この形式に対応したXMLパーサがあった場合、圧縮したまま解析することができる。そのため、図２のステップＳ２１５、Ｓ２１６のデータ伸長に係る処理が不要となる。これにより、データ受信装置１２０側のデータ伸長時の計算時間が減り、データ取得の処理全体が高速化する効果がある。
【００５９】
なお、本実施形態では更に、図２のフローチャートにおいて、ステップＳ２０８、Ｓ２１０で説明した圧縮方式の選択に係る処理が第１の実施形態と異なる。
【００６０】
ステップＳ２０８では圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式を、第１の実施形態と同様に、要求メッセージのHTTPヘッダであるAccept-Encodingの値を参照して決定する。
【００６１】
ここで、データ受信装置１２０がEXI, Fast Infoset形式の圧縮に対応している場合に、要求メッセージ受付部１０１がＨＴＴＰプロトコルで受信した要求メッセージの一例を図８（ａ）に示す。
【００６２】
図８（ａ）では、Accept-Encoding値として、exi, finf, deflateが記述されている。この記述は、データ受信装置１２０が、W3C EXI, ISO Fast Infoset, deflate方式に対応していることを示している。
【００６３】
ステップＳ２１０で圧縮方式選択部１０６は、データ受信装置１２０が対応可能な圧縮方式のうち、ステップＳ２０７で取得したコーデックの種別（識別子）に適した圧縮方式を選択する。圧縮方式選択部１０６は、図７に示す如く、コーデックの種別毎に、それに適した圧縮方式（優先圧縮方式）とＨＴＴＰ標準の圧縮方式と、が登録されたテーブルを保持している。
【００６４】
なお、図７では、コーデック種別の値として前述のFourCC識別子、通常圧縮方式の値として、deflate, gzip, identity（無圧縮）を使用している他、優先圧縮方式として、exi(W3C EXI形式)が定義されている。
【００６５】
図７において欄７０１には様々なコーデックの種別（識別子）が登録されており、欄７０２にはそれぞれのコーデックの種別に適した圧縮方式が登録されており、欄７０３にはそれぞれのコーデックの種別に対応するＨＴＴＰ標準の圧縮方式が登録されている。例えば、図７のテーブルによれば、コーデックの種別が「ｔｘ３ｇ」であれば、それに適した圧縮方式は「exi」となり、ＨＴＴＰ標準の圧縮方式は「deflate」、「gzip」となる。然るに圧縮方式選択部１０６は、図７のテーブルを参照し、先ず、ステップＳ２０７で取得したコーデックの種別に対応する優先圧縮方式を選択する。そして、選択した優先圧縮方式がデータ受信装置１２０が対応可能な圧縮方式であれば、この優先圧縮方式を送信時の圧縮方式として選択する。一方、対応可能な圧縮方式でなければ、ステップＳ２０７で取得したコーデックの種別に対応する通常圧縮方式を、送信時の圧縮方式として選択する。
【００６６】
例えばステップＳ２０２で図５（ａ）に示す要求メッセージを受信した場合、字幕トラック部分のコーデックの種別が”tx3g”であることから、圧縮方式選択部１０６は図７のテーブルより先ず、”tx3g”に対応する圧縮方式「exi」を選択する。次に圧縮方式選択部１０６は、データ受信装置１２０がexi方式に対応していることから、選択した圧縮方式「exi」を送信時の圧縮方式として選択する。この場合に、応答メッセージ生成部１０８により生成される応答メッセージの構成例を図８（ｂ）に示す。
【００６７】
ここで、Content-Range-Mappingヘッダは、メディアフラグメントＵＲＩの仕様で提案されているヘッダであり、応答メッセージに含まれるデータが、track分割方式で分割された動画像データ１３１の一部であることを示す。
【００６８】
また、X-Content-Encodingヘッダは、HTTP圧縮がexi方式で行われたことを示す。通常のHTTP圧縮では、exi方式を記述できないため、HTTPのContent-Encodingヘッダを拡張したヘッダとして記述している。
【００６９】
［第３の実施形態］
第１の実施形態では、分割したデータを圧縮するかどうかの判断を、圧縮効果がある分割方式（第１の実施形態では、track分割方式）の使用の有無から判断した。本実施形態では、図４のＵＲＩ４０４のように、複数の分割方式が指定された場合に、圧縮効果のある分割方式の使用の有無だけでなく、圧縮対象となるデータの範囲（圧縮影響範囲）と合わせて、圧縮するかどうかを判断することを特徴とする。これにより、分割したデータのサイズが小さく、圧縮による送信データのサイズ縮小の効果が少ない場合はデータ圧縮せず、送信側・受信側のデータ圧縮・伸長処理によるＣＰＵ負荷や送信時間の遅延を低減する効果を得る。
【００７０】
先ず、本実施形態に係る送信装置を含むシステムの機能構成例について、図９のブロック図を用いて説明する。図９の１００から１３１については、図１と同じであるため説明を省略する。本実施形態では、圧縮影響範囲を取得する圧縮影響範囲取得部９０１が追加されている点が図１と異なる。
【００７１】
図１０は、本実施形態に係る送信装置が行う処理のフローチャートである。ステップＳ２０１〜Ｓ２０４、ステップＳ２０７〜Ｓ２１７の処理については、図２と同じであるため説明を省略する。
【００７２】
データ分割部１０３がステップＳ２０４において部分データを生成した後、ステップＳ１００１では、圧縮影響範囲取得部９０１が、圧縮影響範囲の値を算出する。なお、本実施形態では、圧縮影響範囲として、分割後のデータサイズの予測値を使用する。分割後のデータサイズは、分割前のデータサイズと各分割形式によるサイズ縮小率の総積（Π）から以下の計算式で求める。
【００７３】
圧縮影響範囲＝（分割前のデータサイズ）×Π（各分割方式によるデータサイズ縮小率）
＝（分割前のデータサイズ）×（temporal分割方式によるデータサイズ縮小率）×（spatial分割方式によるデータサイズ縮小率）×（track分割方式によるデータサイズ縮小率）
【００７４】
また、本実施形態では、各分割方式による縮小率は、以下の計算式で求める。
【００７５】
temporal分割方式によるデータサイズ縮小率＝（分割後の再生時間）÷（分割前の再生時間）
spatial分割方式によるデータサイズ縮小率＝（分割後の画素数）÷（分割前の画素数）
track分割方式によるデータサイズ縮小率＝（分割後のトラック数）÷（分割前のトラック数）
【００７６】
ここで、分割前のデータ(example.mp4)のデータサイズが100MB、再生時間が1800秒、トラック数が3個、画素数が640×360ピクセルだったとする。この場合、図４のＵＲＩ４０４に記述されるメディアフラグメントＵＲＩが指定された時の圧縮影響範囲は、以下のとおりとなる。
【００７７】
圧縮影響範囲＝100MB×{(20−10)÷1800}×{(640×360)÷(640×360)}×{1／3}
＝0.19MB
【００７８】
次に、ステップＳ１００２では、圧縮有効性判断部１０４が、第１の実施形態で説明したデータ分割方式の圧縮有効度と、圧縮影響範囲から圧縮の有効性を示す圧縮有効度と、を算出する。本実施形態では、「圧縮影響範囲から圧縮の有効性を示す圧縮有効度」は、以下の計算式で算出する。
【００７９】
圧縮有効度＝（データ分割方式の圧縮有効度）×（圧縮影響範囲）＝ １×0.19 = 0.19MB
【００８０】
なお、データ分割方式の圧縮有効度についての説明は、第１の実施形態で行ったため、ここでは省略する。
【００８１】
次に、ステップＳ１００３では、圧縮有効性判断部１０４は、送信装置にあらかじめ設定してあった圧縮有効度の閾値を参照し、圧縮有効度が閾値より大きかったら圧縮が有効と判断し、処理はステップＳ２０７に進む。一方、閾値以下だったら、圧縮が無効と判断し、処理はステップＳ２１２に進む。たとえば、圧縮有効度が0.19MBで閾値が1MBであった場合、分割後のデータは圧縮されずに、処理はステップＳ２１２に進むことになる。なお、その後の処理については、第１の実施形態と同じであるため、説明を省略する。
【００８２】
なお、本実施形態では、データサイズ縮小率を算出する際、動画像の圧縮率が全時刻で一様かつ、全領域で一様かつ、全トラックで一様と仮定し、分割範囲とデータサイズに比例関係が成立するとして計算した。しかし、動画像の詳細な縮小率が取得できる場合、その値を用いて計算してもよい。例えば、特定の時刻の縮小率がPtemp(t)、特定の領域の縮小率がPs(x, y, w, h, t)、特定のトラックの縮小率がPtr(tr, t)だったとする。この場合、圧縮影響範囲は以下の計算式から求めることができる。
【００８３】
圧縮影響範囲
＝分割前のデータサイズ×∫t=tst=tePtemp(t)Ps(x, y, w, h, t)Ptr(tr, t)dt
【００８４】
ここで、t: 特定の時刻を表す変数、ts:部分データの開始時刻、te:部分データの終了時刻、x:部分データのx座標、y:部分データのy座標、w:部分データの幅、h:部分データの高さ、tr:部分データのトラック種別である。
【００８５】
［第４の実施形態］
Deflateなどのデータ圧縮アルゴリズムでは、圧縮時に圧縮レベルを設定することが可能である。一般に、圧縮レベルが高い場合は、圧縮率は高くなるが、圧縮処理時間が長くなるという傾向がある。
【００８６】
第３の実施形態では、ステップＳ１００３の処理において圧縮有効性判断部１０４は、分割結果のデータを圧縮するかどうかを1つの閾値で判断した。本実施形態では、圧縮有効性判断部１０４は、複数の閾値を使用し、圧縮をするかどうかだけでなく、圧縮する際に指定する圧縮レベルを判断する。これにより、圧縮実行部１０７が、圧縮方式選択部１０６が選択した圧縮方式にしたがって分割データを圧縮する際に、分割データに合わせた圧縮レベルで圧縮処理を行うことができる。すなわち、分割後のデータのサイズが大きい場合には圧縮率を重視した圧縮レベルを使用してデータサイズを小さくすることで通信負荷を下げ、小さい場合には圧縮時間を重視した圧縮レベルを使用することができる。
【００８７】
図１１は、複数の閾値と圧縮レベルとを対応づけた圧縮レベル対応表の例である。圧縮有効度欄１１０１には、それぞれの圧縮有効度に対する閾値が記述されている。圧縮レベル欄１１０２には、各閾値に対応する圧縮レベルが記述されている。圧縮有効性判断部１０４は、ステップＳ１００３の処理でこの圧縮レベル対応表を参照し、例えば、圧縮有効度が1MB未満のときは圧縮が無効と判断する。また、10MB未満のとき圧縮レベル4を使用すると判断する。さらに10MB以上のとき、圧縮レベル9を使用すると判断する。なお、この圧縮レベル対応表は、メモリ１１１内に保持されているものとする。
【００８８】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項１】
外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、
マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段と、
前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する手段と、
前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する手段と、
前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得手段と、
前記取得手段が取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信手段と
を備えることを特徴とする送信装置。
【請求項２】
前記要求メッセージには、前記外部装置が対応可能な圧縮方式を規定する第３の記述、が含まれており、
前記送信手段は、前記値が前記閾値よりも大きい場合、前記部分データのコーデックの種別を取得し、該取得したコーデックの種別に対して予め設定された圧縮方式を取得し、該取得した圧縮方式と前記第３の記述が規定する圧縮方式とで共通の圧縮方式に従って前記部分データを圧縮し、該圧縮により得られる前記圧縮データを前記外部装置に対して送信する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
前記第２の記述が２つ以上の方式を規定する場合、
前記取得手段は、前記２つ以上の方式のそれぞれに対応する係数を前記保持手段から取得し、
前記送信手段は、前記２つ以上の方式のそれぞれについて前記取得手段が取得した係数の総和を前記値とし、該値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、該値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する
ことを特徴とする請求項１又は２に記載の送信装置。
【請求項４】
更に、
前記マルチメディアデータのデータサイズと、該マルチメディアデータから部分的なデータを抽出する方式毎の圧縮率と、の積を取得する手段を備え、
前記送信手段は、前記積と、前記取得手段が取得した係数の総和と、の積を前記値として算出し、該算出した値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する
ことを特徴とする請求項３に記載の送信装置。
【請求項５】
前記送信手段は、前記値に対して予め対応づけられている圧縮方式に従って前記部分データを圧縮し、該圧縮によって得られる圧縮データを外部装置に対して送信する
ことを特徴とする請求項４に記載の送信装置。
【請求項６】
外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段を有する前記送信装置が行う送信方法であって、
前記送信装置の受信手段が、前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する工程と、
前記送信装置の抽出手段が、前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する工程と、
前記送信装置の取得手段が、前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得工程と、
前記送信装置の送信手段が、前記取得工程で取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信工程と
を備えることを特徴とする送信方法。
【請求項７】
コンピュータを請求項１乃至５の何れか１項に記載の送信装置の各手段として機能させるためのコンピュータプログラム。
【請求項１】
外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、
マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段と、
前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する手段と、
前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する手段と、
前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得手段と、
前記取得手段が取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信手段と
を備えることを特徴とする送信装置。
【請求項２】
前記要求メッセージには、前記外部装置が対応可能な圧縮方式を規定する第３の記述、が含まれており、
前記送信手段は、前記値が前記閾値よりも大きい場合、前記部分データのコーデックの種別を取得し、該取得したコーデックの種別に対して予め設定された圧縮方式を取得し、該取得した圧縮方式と前記第３の記述が規定する圧縮方式とで共通の圧縮方式に従って前記部分データを圧縮し、該圧縮により得られる前記圧縮データを前記外部装置に対して送信する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
前記第２の記述が２つ以上の方式を規定する場合、
前記取得手段は、前記２つ以上の方式のそれぞれに対応する係数を前記保持手段から取得し、
前記送信手段は、前記２つ以上の方式のそれぞれについて前記取得手段が取得した係数の総和を前記値とし、該値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、該値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する
ことを特徴とする請求項１又は２に記載の送信装置。
【請求項４】
更に、
前記マルチメディアデータのデータサイズと、該マルチメディアデータから部分的なデータを抽出する方式毎の圧縮率と、の積を取得する手段を備え、
前記送信手段は、前記積と、前記取得手段が取得した係数の総和と、の積を前記値として算出し、該算出した値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する
ことを特徴とする請求項３に記載の送信装置。
【請求項５】
前記送信手段は、前記値に対して予め対応づけられている圧縮方式に従って前記部分データを圧縮し、該圧縮によって得られる圧縮データを外部装置に対して送信する
ことを特徴とする請求項４に記載の送信装置。
【請求項６】
外部装置から要求されたデータを該外部装置に対して送信する送信装置であって、マルチメディアデータから部分的なデータを抽出する方式毎に、該方式により抽出されるデータに対する圧縮の有効度を示す係数を保持する保持手段を有する前記送信装置が行う送信方法であって、
前記送信装置の受信手段が、前記マルチメディアデータから抽出する部分を規定する第１の記述、該部分を抽出する方式を規定する第２の記述、を含む要求メッセージを前記外部装置から受信する工程と、
前記送信装置の抽出手段が、前記マルチメディアデータから、前記第１の記述により規定されている部分を部分データとして抽出する工程と、
前記送信装置の取得手段が、前記第２の記述により規定されている方式に対応する係数を前記保持手段から取得する取得工程と、
前記送信装置の送信手段が、前記取得工程で取得した係数に応じた値が閾値よりも大きい場合、前記部分データを圧縮して得られる圧縮データを外部装置に対して送信し、前記値が前記閾値よりも小さい場合は、前記部分データを前記外部装置に対して送信する送信工程と
を備えることを特徴とする送信方法。
【請求項７】
コンピュータを請求項１乃至５の何れか１項に記載の送信装置の各手段として機能させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−１４２９１９（Ｐ２０１２−１４２９１９Ａ）
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願番号】特願２０１１−２５１９１９（Ｐ２０１１−２５１９１９）
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]