JP3976191B2 - サーバ、送信レート制御方法、プログラムおよび記録媒体 - Google Patents
サーバ、送信レート制御方法、プログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP3976191B2 JP3976191B2 JP2003001217A JP2003001217A JP3976191B2 JP 3976191 B2 JP3976191 B2 JP 3976191B2 JP 2003001217 A JP2003001217 A JP 2003001217A JP 2003001217 A JP2003001217 A JP 2003001217A JP 3976191 B2 JP3976191 B2 JP 3976191B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- video
- bit rate
- network
- audio 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.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを経由して映像や音声に係るデータを送信する技術に係る。
【０００２】
【従来の技術】
インターネット等のネットワークを経由して、サーバからユーザ端末に映像や音声に係るデータ（以下、映像音声データという）を送信するシステムがある。データの送り手であるサーバは、ネットワークの帯域を検知した上で、送信するデータ量（ビットレート）を調整する。ここで、データ量を調整する手段としては、（１）符号化装置（エンコーダ）の圧縮率を変えてデータ量を変化させる方法、（２）予め複数の圧縮率で符号化したデータを用意しておき、符号化したデータの平均データ量に基づき、いずれかのデータを送信する方法が知られている（非特許文献１参照）。
【０００３】
【非特許文献１】
萩野，尾上，安木，渥美，駒木，村尾，串田，山内，「モバイルストリーミングQoSサーバにおけるファイル切り替え方式」，信学技法，MoMUc2001-121，pp91−pp98，Mar.2002
【０００４】
【発明が解決しようとする課題】
上述した（１）の方法では、実際に符号化処理を完了するまで、どの程度データ量が変化するのかわからず、必要以上にデータ量を落とす／上げる制御をしてしまうおそれがあった。たとえば、必要以上にビットレートを落としてしまった結果、データを受けたユーザ端末において再生映像の画質が急激に悪化してしまう問題があった。
【０００５】
一方、（２）の方法によれば、予め符号化処理を行っておくから、上述したような問題は生じない。しかしながら、（２）の方法では、符号化データのうち一時的にデータ量が増えた場合に、ネットワークの帯域を無視したデータ送信制御が行なわれ、データ輻輳やパケットロス等を引き起こしていた。そして、ユーザ端末において正常な映像再生ができない問題につながっていた。
本発明は、以上述べたような諸問題を生じることなく、ネットワークを経由して映像音声データを問題なく送信するための技術を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した課題を解決するために、本発明に係るサーバは、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する記憶部と、前記ネットワークの帯域を検知する検知部と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する制御部とを有することを特徴とする。
かかるサーバの構成によれば、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートがそれぞれ記憶されており、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知したネットワークの帯域以下のものが送信レートとして決定される。このため、常にネットワークの帯域に沿ったビットレートによるデータ送信が行われることになる。
【０００７】
上述したサーバの構成において、前記記憶部は、前記映像音声データの再生経過時が同じ分割データに係るビットレートについて並べた管理テーブルであって、前記一定時間ごとにビットレートの低い／高い順に内容が更新される管理テーブルを記憶し、前記制御部は、前記管理テーブルにおけるビットレートの値のうち、検知した帯域が指定するビットレート上限値以下であって当該上限値に一番近いものを送信レートとして決定することを特徴としてもよい。
この場合、管理テーブルの内容は、一定時間ごとにビットレートの低い／高い順に内容が更新されるから、検知した帯域が指定するビットレート上限値以下であって当該上限値に一番近いものを送信レートして決定する際の便宜性が図られる。
【０００８】
本発明に係る送信レート制御方法は、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する過程と、前記ネットワークの帯域を検知する過程と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する過程とを有することを特徴とする。
かかる方法を用いれば、ネットワークの帯域以下のビットレートで常にデータ送信を行うことができ、ネットワークにおけるデータ輻輳やパケットロスといった問題は生じるおそれがない。
【０００９】
本発明に係るプログラムは、サーバを、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する手段と、前記ネットワークの帯域を検知する手段と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する手段として機能させることを特徴とする。
かかるプログラムを利用すれば、ネットワークの帯域以下のビットレートで常にデータ送信を行うことができ、ネットワークにおけるデータ輻輳やパケットロスといった問題は生じるおそれがない。
上述したプログラムはＦＤ（Ｆｌｏｐｐｙ（登録商標） Ｄｉｓｋ）やＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）といった各種記録媒体に記録しておけば、プログラムのインストール時やプログラム取引の際の便宜性が図られる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施形態の内容について、図面を用いながら説明する。
図１は、本発明を適用したデータ送信システム（以下、単にシステムという）１００の構成図である。図１に示したよりも多くのユーザ端末１０が存在していてもよい。
本システム１００は、サーバ３０からネットワーク２０を経由してユーザ端末１０映像音声データを送信するシステムである。本実施形態に係る映像音声データは、たとえば映画等のコンテンツに係るデータであり、ＭＰＥＧ４（Moving Picture Experts Group phase4）の規格で符号化されているものを想定する。なお、符号化の規格はＭＰＥＧ２やＭＰ３（MPEG-1 Audio Layer3）といった他のものであってもよい。
【００１１】
ユーザ端末１０は、携帯電話機などであり、サーバ３０から送信された映像音声データをデコードし、映像や音声の再生処理をする。
ネットワーク２０は、インターネットなどのデータ通信網である。ネットワーク２０において通信を共有する端末の数に応じて、ネットワーク２０の帯域は変動する。
サーバ３０は、たとえばＰＣ（パーソナルコンピュータ）であり、ＣＰＵ（中央演算ユニット）やハードディスク（記憶部）を有している。サーバ３０には、ＭＰＥＧ４の規格による符号化処理や、ネットワーク２０の帯域を検知するためのプログラム等が予めインストールされている。
【００１２】
次に、本実施形態の内容を特徴付けるサーバ３０の動作の内容を説明する。図２は、サーバ３０において、ユーザ端末１０に映像音声データを送信する準備段階として、データの符号化やデータを管理するための各種テーブルを生成する際の処理内容を示すフローチャートである。以下、図２に沿って説明する。
【００１３】
（１）映像ファイルの作成（図２：ステップＳａ１）
サーバ３０は、１つの映像音声（コンテンツ）データにつき、異なる圧縮率（符号化レート）により圧縮処理（符号化処理）し、圧縮データに係るファイル（映像ファイル）を作成する。映像ファイルの内容は、ＭＰＥＧ４の規格に基づく符号化データ、たとえば１秒あたり１５フレームのフレームデータを集めたものになる。
図３に、映像ファイルを生成する過程の概念図を示した。一つの映像音声データを、符号化レートＲ１で符号化して映像ファイルＦ１を生成する。また、同じ映像音声データを別の符号化レートＲ２で符号化して映像ファイルＦ２を作成する。他の映像ファイルも同様に生成する。
各々の映像ファイルＦ１，Ｆ２，……、は、単位時間（１秒）あたり１５フレームのフレームデータを包含している点で共通するが、異なる符号化レートで符号化しているため、各々の映像ファイルＦ１，Ｆ２，……、の圧縮率は異なるものになっている。
【００１４】
（２）インデックス番号等の決定（図２：ステップＳａ２）
次にサーバ３０は、生成した映像ファイルＦ１，Ｆ２，……、のそれぞれについて、予め決められるいくつかのパターン（間引きパターン）で間引き処理を行っていく。間引き処理とは、単位時間（１秒）あたりに含まれる１５のフレームデータごとに行う処理である。
本実施形態においては、個々の映像ファイルについて、映像音声の再生開始時から一定経過時間（１秒）ごとに分割して得られる分割データ、すなわち、１５のフレームデータごとに分割した分割データを、「単位データ」と呼ぶことにする。
【００１５】
図４は、映像ファイルＦ１に包含される一の単位データに着目し、この単位データに対して間引き処理をする概念を示したものである。なお図４に示す映像ファイルＦ１は、一般的なＭＰＥＧフォーマット（ＭＰＥＧ１やＭＰＥＧ２）を考慮し、Ｉフレームデータ、Ｐフレームデータ、Ｂフレームデータと３種のフレームデータにより構成されることとしたが、ＭＰＥＧ４のフォーマットを用いた場合はＩフレームデータとＰフレームデータのみの構成となる。
【００１６】
図４では、間引きパターンとして２種類（間引きパターンａ，ｂ）示しており、このうち間引きパターンａは、単位データの先頭に位置するフレームデータ（Ｉフレームデータ）を残し、その他のフレームデータを間引く処理をするものである。
また、間引きパターンｂは、単位データに含まれるＩフレームデータおよびＰフレームデータを残し、その他のフレームデータ（Ｂフレームデータ）を間引く処理をするものである。
【００１７】
このような間引きパターンは、各フレームデータの性質に基づいて予め決められている。たとえばＩフレームは他のＰフレームやＢフレームからのデータ依存性がないため、Ｉフレームデータを残すように間引き処理（間引きパターンａ）してもその後の再生処理を問題なく行うことができる。また、Ｐフレームは同じ単位データ内のＩフレーム（あるいはＰフレーム）からのデータ依存性があるから、ＩフレームとＰフレームのデータを残すように間引き処理（間引きパターンｂ）すれば、その後の再生処理を問題なく実行できる。
このように、間引き処理後のデータ処理を踏まえた間引きパターンが予め用意されており、これにより、同じ単位データについて複数の間引きパターンで間引き処理をし、データ量が異なる新たな単位データを複数生成するのである。
【００１８】
以上、映像ファイルＦ１の１つの単位データに着目して、間引き処理の内容を具体的に説明したが、このような間引き処理は映像ファイルＦ１に含まれるすべての単位データに対して行われる。
図５は、映像ファイルＦ１に含まれる単位データの内容を模式的に示したものである。映像ファイルＦ１の先頭に位置するの単位データから終点に位置する単位データの順に、単位データＦ１−１，Ｆ１−２，……，Ｆ１−ｎと表した。映像ファイルＦ１の最後に位置する単位データはＦ１−ｎであり、本実施形態においては単位データは１秒あたりのデータに相当するため、ｎは映像音声（コンテンツ）の再生時間長を示す自然数である。
このような映像ファイルＦ１における、単位データＦ１−１，Ｆ１−２，……，Ｆ１−ｎのそれぞれについて、間引き処理ａをすることにより生成した単位データを、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎと表し、間引き処理ｂをすることにより生成した単位データを、単位データＦ１−ｂ１，Ｆ１−ｂ２，……，Ｆ１−ｂｎと表した。
【００１９】
図６は、このようにして生成した単位データの各々について、サーバ３０に格納した状態を示す概念図である。個々の単位データには、単位データを特定するための名前（識別番号）と、当該単位データのデータ量をあわせて示した。本実施形態において単位データは１秒あたりのデータに対応するから、個々の単位データのデータ量は、ネットワーク２０を経由して送信する際のビットレートに相当することになる。
【００２０】
図６に示すように、サーバ３０は、個々の単位データについて、映像ファイルの先頭から終点に向かう順に格納していく。このため、図６において、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生（デコード）処理すると、一の映像音声の再生が行われることになる。また、単位データＦ１−ａ１と単位データＦ１−ｂ１とは、データ量、すなわち再生した際の映像や音声の品質は違うものの、その内容は同一である。
このため、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生処理した場合であっても、単位データＦ１−ａ１を単位データＦ１−ｂ１に置き換えて、単位データＦ１−ｂ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生処理した場合であっても、得られる映像音声の品質は異なるものの、その内容は同一である。
【００２１】
以上は、映像ファイルＦ１に対し、間引きパターンａ，ｂ，……、で間引き処理を行った場合の内容を説明したが、映像ファイルＦ１と同様にして映像ファイルＦ２，Ｆ３，……、についても、それぞれ間引きパターンａ，ｂ，……、により間引き処理を行っていく。そして、サーバ３０は、生成した単位データについて、図６に示すようにして、映像ファイルの先頭から終点に向かう順に格納していく。
図６において、個々の単位データは、映像音声（コンテンツ）の１秒分のデータに相当し、コンテンツ開始からの時間順に格納されている点では同じである。このため、図６において、縦軸位置を同じに示した単位データＦ１−ａ１，Ｆ１−ｂ２，……，Ｆ２−ａ１，Ｆ２−ｂ１，……、は、ビットレートは異なるものの、再生処理をして得られるコンテンツ（映像）の内容はほとんど同じものになる。
【００２２】
サーバ３０は、このようにして個々の単位データを格納した後、映像ファイルと間引き処理の組み合わせによって一義に決められる単位データ群（たとえば、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎのデータ群）ごとにビットレートの平均値を算出する。そして、ビットレートの平均値の低いほうから順に、インデックス番号を付しておく（図６参照）。
【００２３】
（３）管理テーブルの作成（図２：ステップＳａ３）
その後、サーバ３０は、インデックス番号の若い順、すなわち、平均ビットレートが低い順に並べ替えを行い管理テーブルを作成する。図７は、管理テーブルの内容を図示したものである。従来のデータ送信システムにおいては、平均ビットレートの値をもとに、データ送信時のビットレート制御を行っていた。このため、一時的にビットレートが大きく／小さく変化する現象を検知することができず、ネットワーク２０における諸問題（データ輻輳やパケットロス等）が生じることとなっていたのは上述したとおりである。
【００２４】
（４）動的管理テーブルの作成（図２：ステップＳａ４）
次にサーバ３０は、本実施形態の特徴である動的管理テーブルを生成する。動的管理テーブルは、映像音声データの送信開始時（映像音声データの再生開始時に相当）から単位時間（本実施形態では１秒）ごとに生成（更新）されるテーブルである。
【００２５】
図８は、映像音声データの再生開始時点（映像音声データを送信するときは送信開始時点に相当）を０秒としたときの、コンテンツ開始から０秒目と、１秒経過時点における動的管理テーブルの内容を示したものである。
ここで、０秒目における動的管理テーブルは、０秒〜１秒に相当する単位データ（図６における単位データＦ１−ａ１，Ｆ１−ｂ１，……，Ｆ２−ａ１，Ｆ２−ｂ１，……）のビットレートが低い順に並び替えたものである。また、１秒経過後における動的管理テーブルは、コンテンツ開始から１秒〜２秒に相当する単位データ（図６における単位データＦ１−ａ１，Ｆ１−ｂ１，……，Ｆ２−ａ１，Ｆ２−ｂ１，……）のビットレートが低い順に並び替えたものである。
【００２６】
図８に示されるように、動的管理テーブルの並び順は、インデックス番号、すなわち、平均ビットレートの順番とは無関係であり、その時点における単位データのビットレートの低い順に並べたものである。このため、ある単位データが一時的にビットレートが高く／低くなるような場合であっても、その内容が動的管理テーブルには忠実に反映されることになるのである。
以上が図２のフローチャートの内容説明である。
【００２７】
このようにして生成される動的管理テーブルの内容に基づいて、サーバ３０は、ユーザ端末１０に映像音声データを送信する。
図９は、サーバ３０が映像音声データを送信する際の動作の内容を示すフローチャートである。
ユーザ端末１０に映像音声データの送信を開始する際、サーバ３０は、はじめにネットワーク２０の帯域について検知してビットレートの上限値を判別する（ステップＳｂ１）。なお、ネットワーク２０の帯域を検知したり、ビットレートの上限値を判別するためのプログラムは予めサーバ３０にインストールされている。
【００２８】
次にサーバ３０は、該時点（ここでは映像音声データの再生開始時点）における動的管理テーブルを生成する（ステップＳｂ２）。この時点の動的管理テーブルは、映像音声データの再生開始時点における単位データについて、データ量（ビットレート値）が小さい順に並べたテーブルに相当する。サーバ３０は、判別したビットレート上限値に内輪で最も近いビットレートの単位データを、動的管理テーブルの内容から判断し、送信データとして決定する（ステップＳｂ３）。
【００２９】
図８に例示する動的管理テーブルを用いて説明する。図８において左側のテーブルが、映像音声データ再生開始時（データ送信開始時）の動的管理テーブルである。ネットワーク２０のビットレート上限値が２７０００（ｂｐｓ）であるとすると、サーバ３０は、２７０００（ｂｐｓ）の内輪で一番近い、インデックス番号００３の単位データＦ１−ｂ１を、送信データとして決定する。その後、サーバ３０は、このようにして決定した送信データを、実際にユーザ端末１０に送信する（図９：ステップＳｂ４）。
【００３０】
以上は、映像音声データの再生開示時（データ送信開始時）におけるサーバ３０の動作内容であったが、その後も、サーバ３０は所定時間（１秒）ごとに、ネットワーク２０の帯域を検知する（ステップＳｂ１）。そして、動的管理テーブルの内容を生成（更新）していく（ステップＳｂ２）。たとえば、映像音声データを送信開始後１秒の時点であれば、サーバ３０は、映像音声データの再生開始から１秒経過時点における単位データについて、データ量（ビットレート値）を小さい順に並べかえをして動的管理テーブルの内容を更新する。この後の処理は同様であり、サーバ３０は、判別したビットレート上限値に内輪で最も近いビットレートの単位データを、更新した動的管理テーブルの内容から判断し、送信データとして決定する（ステップＳｂ３）。そしてユーザ端末１０に送信する（ステップＳｂ４）。
【００３１】
図８に例示する動的管理テーブルを用いて説明する。図８において右側のテーブルが、映像音声データ再生開始から１秒経過後（データ送信開始から１秒後）の動的管理テーブルである。ここで、ネットワーク２０のビットレート上限値が２７０００（ｂｐｓ）であるとすると、サーバ３０は、２７０００（ｂｐｓ）の内輪で一番近い、インデックス番号００２の単位データＦ２−ａ２を、送信データとして決定することになる。
【００３２】
その後も、サーバ３０は同様の制御を繰り返し、映像音声データを送信していく。１秒ごとに、動的管理テーブルの内容は更新され、その時点における単位データのデータレートの低い順に並べ替えが行われることになる。このため、ネットワーク２０のビットレート上限値に内輪で最も近い単位データについて迅速に見つけ出すことができるように図られている。
【００３３】
以上説明したように、本実施形態によれば、ネットワーク２０を経由し、単位データにより構成される映像音声データ（ストリームデータ）を送信するにあたり、送信する単位データの候補として、圧縮率（データ量）が異なるものを予め用意しておく。そして、ネットワーク２０の帯域を検知して判断したビットレートの上限値について、内輪で最も近い単位データを送信するようにするから、ネットワーク２０を経由するデータ通信は常に正常に行われ、従来に問題となっていた、データ輻輳やパケットロス等の問題は生じない。
【００３４】
なお上述した各実施形態の内容は、あくまで一例であり、任意に変形を加えることができる。以下に変形例のいくつかを示す。
サーバ３０には、各々の単位データに係るデータ量（ビットレート）の情報が記憶されてさえいれば、ネットワーク２０の帯域に適した単位データを送信するという、本発明の効果を奏することができる。このため、単位データそのものをサーバ３０内に格納しておき、随時読み出してデータ送信を行ってもよいし、単位データそのものはサーバ３０内に格納することなく、データ送信時に随時生成する構成をとってもよい。
【００３５】
また、本発明に係るプログラムのインストール方法は任意である。上述実施形態においては、予めサーバ３０にインストールしている場合を想定したが、プログラムの内容を記憶した記憶媒体（フロッピーディスクやＣＤ−ＲＯＭ等）を介して、サーバ３０にインストールしてもよい。また、ネットワーク２０やその他の網を介してインストールする、いわゆるネット配信を利用する形態であってもよい。
【００３６】
【発明の効果】
以上説明したように、本発明によれば、ネットワークの帯域に応じた映像音声データの送信を問題なく行うことができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態に係るデータ送信システム１００の構成図である。
【図２】 同データ送信システム１００のサーバ３０が各種テーブルを作成する手順を示すフローチャートである。
【図３】 同サーバ３０が映像ファイルを作成する処理内容を示す概念図である。
【図４】 同サーバ３０が行う間引き処理の内容を示す概念図である。
【図５】 同サーバ３０が作成した映像ファイルの内容を説明するための図である。
【図６】 同サーバ３０に単位データが格納された状態を示す概念図である。
【図７】 同サーバ３０に格納される管理テーブルの内容を示す図である。
【図８】 同サーバ３０に格納される動的管理テーブルの内容を示す図である。
【図９】 同サーバ３０の動作内容を示すフローチャートである。
【符号の説明】
１０……ユーザ端末、２０……ネットワーク、
３０……サーバ、１００……データ送信システム。
【発明の属する技術分野】
本発明は、ネットワークを経由して映像や音声に係るデータを送信する技術に係る。
【０００２】
【従来の技術】
インターネット等のネットワークを経由して、サーバからユーザ端末に映像や音声に係るデータ（以下、映像音声データという）を送信するシステムがある。データの送り手であるサーバは、ネットワークの帯域を検知した上で、送信するデータ量（ビットレート）を調整する。ここで、データ量を調整する手段としては、（１）符号化装置（エンコーダ）の圧縮率を変えてデータ量を変化させる方法、（２）予め複数の圧縮率で符号化したデータを用意しておき、符号化したデータの平均データ量に基づき、いずれかのデータを送信する方法が知られている（非特許文献１参照）。
【０００３】
【非特許文献１】
萩野，尾上，安木，渥美，駒木，村尾，串田，山内，「モバイルストリーミングQoSサーバにおけるファイル切り替え方式」，信学技法，MoMUc2001-121，pp91−pp98，Mar.2002
【０００４】
【発明が解決しようとする課題】
上述した（１）の方法では、実際に符号化処理を完了するまで、どの程度データ量が変化するのかわからず、必要以上にデータ量を落とす／上げる制御をしてしまうおそれがあった。たとえば、必要以上にビットレートを落としてしまった結果、データを受けたユーザ端末において再生映像の画質が急激に悪化してしまう問題があった。
【０００５】
一方、（２）の方法によれば、予め符号化処理を行っておくから、上述したような問題は生じない。しかしながら、（２）の方法では、符号化データのうち一時的にデータ量が増えた場合に、ネットワークの帯域を無視したデータ送信制御が行なわれ、データ輻輳やパケットロス等を引き起こしていた。そして、ユーザ端末において正常な映像再生ができない問題につながっていた。
本発明は、以上述べたような諸問題を生じることなく、ネットワークを経由して映像音声データを問題なく送信するための技術を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した課題を解決するために、本発明に係るサーバは、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する記憶部と、前記ネットワークの帯域を検知する検知部と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する制御部とを有することを特徴とする。
かかるサーバの構成によれば、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートがそれぞれ記憶されており、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知したネットワークの帯域以下のものが送信レートとして決定される。このため、常にネットワークの帯域に沿ったビットレートによるデータ送信が行われることになる。
【０００７】
上述したサーバの構成において、前記記憶部は、前記映像音声データの再生経過時が同じ分割データに係るビットレートについて並べた管理テーブルであって、前記一定時間ごとにビットレートの低い／高い順に内容が更新される管理テーブルを記憶し、前記制御部は、前記管理テーブルにおけるビットレートの値のうち、検知した帯域が指定するビットレート上限値以下であって当該上限値に一番近いものを送信レートとして決定することを特徴としてもよい。
この場合、管理テーブルの内容は、一定時間ごとにビットレートの低い／高い順に内容が更新されるから、検知した帯域が指定するビットレート上限値以下であって当該上限値に一番近いものを送信レートして決定する際の便宜性が図られる。
【０００８】
本発明に係る送信レート制御方法は、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する過程と、前記ネットワークの帯域を検知する過程と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する過程とを有することを特徴とする。
かかる方法を用いれば、ネットワークの帯域以下のビットレートで常にデータ送信を行うことができ、ネットワークにおけるデータ輻輳やパケットロスといった問題は生じるおそれがない。
【０００９】
本発明に係るプログラムは、サーバを、ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する手段と、前記ネットワークの帯域を検知する手段と、前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する手段として機能させることを特徴とする。
かかるプログラムを利用すれば、ネットワークの帯域以下のビットレートで常にデータ送信を行うことができ、ネットワークにおけるデータ輻輳やパケットロスといった問題は生じるおそれがない。
上述したプログラムはＦＤ（Ｆｌｏｐｐｙ（登録商標） Ｄｉｓｋ）やＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）といった各種記録媒体に記録しておけば、プログラムのインストール時やプログラム取引の際の便宜性が図られる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施形態の内容について、図面を用いながら説明する。
図１は、本発明を適用したデータ送信システム（以下、単にシステムという）１００の構成図である。図１に示したよりも多くのユーザ端末１０が存在していてもよい。
本システム１００は、サーバ３０からネットワーク２０を経由してユーザ端末１０映像音声データを送信するシステムである。本実施形態に係る映像音声データは、たとえば映画等のコンテンツに係るデータであり、ＭＰＥＧ４（Moving Picture Experts Group phase4）の規格で符号化されているものを想定する。なお、符号化の規格はＭＰＥＧ２やＭＰ３（MPEG-1 Audio Layer3）といった他のものであってもよい。
【００１１】
ユーザ端末１０は、携帯電話機などであり、サーバ３０から送信された映像音声データをデコードし、映像や音声の再生処理をする。
ネットワーク２０は、インターネットなどのデータ通信網である。ネットワーク２０において通信を共有する端末の数に応じて、ネットワーク２０の帯域は変動する。
サーバ３０は、たとえばＰＣ（パーソナルコンピュータ）であり、ＣＰＵ（中央演算ユニット）やハードディスク（記憶部）を有している。サーバ３０には、ＭＰＥＧ４の規格による符号化処理や、ネットワーク２０の帯域を検知するためのプログラム等が予めインストールされている。
【００１２】
次に、本実施形態の内容を特徴付けるサーバ３０の動作の内容を説明する。図２は、サーバ３０において、ユーザ端末１０に映像音声データを送信する準備段階として、データの符号化やデータを管理するための各種テーブルを生成する際の処理内容を示すフローチャートである。以下、図２に沿って説明する。
【００１３】
（１）映像ファイルの作成（図２：ステップＳａ１）
サーバ３０は、１つの映像音声（コンテンツ）データにつき、異なる圧縮率（符号化レート）により圧縮処理（符号化処理）し、圧縮データに係るファイル（映像ファイル）を作成する。映像ファイルの内容は、ＭＰＥＧ４の規格に基づく符号化データ、たとえば１秒あたり１５フレームのフレームデータを集めたものになる。
図３に、映像ファイルを生成する過程の概念図を示した。一つの映像音声データを、符号化レートＲ１で符号化して映像ファイルＦ１を生成する。また、同じ映像音声データを別の符号化レートＲ２で符号化して映像ファイルＦ２を作成する。他の映像ファイルも同様に生成する。
各々の映像ファイルＦ１，Ｆ２，……、は、単位時間（１秒）あたり１５フレームのフレームデータを包含している点で共通するが、異なる符号化レートで符号化しているため、各々の映像ファイルＦ１，Ｆ２，……、の圧縮率は異なるものになっている。
【００１４】
（２）インデックス番号等の決定（図２：ステップＳａ２）
次にサーバ３０は、生成した映像ファイルＦ１，Ｆ２，……、のそれぞれについて、予め決められるいくつかのパターン（間引きパターン）で間引き処理を行っていく。間引き処理とは、単位時間（１秒）あたりに含まれる１５のフレームデータごとに行う処理である。
本実施形態においては、個々の映像ファイルについて、映像音声の再生開始時から一定経過時間（１秒）ごとに分割して得られる分割データ、すなわち、１５のフレームデータごとに分割した分割データを、「単位データ」と呼ぶことにする。
【００１５】
図４は、映像ファイルＦ１に包含される一の単位データに着目し、この単位データに対して間引き処理をする概念を示したものである。なお図４に示す映像ファイルＦ１は、一般的なＭＰＥＧフォーマット（ＭＰＥＧ１やＭＰＥＧ２）を考慮し、Ｉフレームデータ、Ｐフレームデータ、Ｂフレームデータと３種のフレームデータにより構成されることとしたが、ＭＰＥＧ４のフォーマットを用いた場合はＩフレームデータとＰフレームデータのみの構成となる。
【００１６】
図４では、間引きパターンとして２種類（間引きパターンａ，ｂ）示しており、このうち間引きパターンａは、単位データの先頭に位置するフレームデータ（Ｉフレームデータ）を残し、その他のフレームデータを間引く処理をするものである。
また、間引きパターンｂは、単位データに含まれるＩフレームデータおよびＰフレームデータを残し、その他のフレームデータ（Ｂフレームデータ）を間引く処理をするものである。
【００１７】
このような間引きパターンは、各フレームデータの性質に基づいて予め決められている。たとえばＩフレームは他のＰフレームやＢフレームからのデータ依存性がないため、Ｉフレームデータを残すように間引き処理（間引きパターンａ）してもその後の再生処理を問題なく行うことができる。また、Ｐフレームは同じ単位データ内のＩフレーム（あるいはＰフレーム）からのデータ依存性があるから、ＩフレームとＰフレームのデータを残すように間引き処理（間引きパターンｂ）すれば、その後の再生処理を問題なく実行できる。
このように、間引き処理後のデータ処理を踏まえた間引きパターンが予め用意されており、これにより、同じ単位データについて複数の間引きパターンで間引き処理をし、データ量が異なる新たな単位データを複数生成するのである。
【００１８】
以上、映像ファイルＦ１の１つの単位データに着目して、間引き処理の内容を具体的に説明したが、このような間引き処理は映像ファイルＦ１に含まれるすべての単位データに対して行われる。
図５は、映像ファイルＦ１に含まれる単位データの内容を模式的に示したものである。映像ファイルＦ１の先頭に位置するの単位データから終点に位置する単位データの順に、単位データＦ１−１，Ｆ１−２，……，Ｆ１−ｎと表した。映像ファイルＦ１の最後に位置する単位データはＦ１−ｎであり、本実施形態においては単位データは１秒あたりのデータに相当するため、ｎは映像音声（コンテンツ）の再生時間長を示す自然数である。
このような映像ファイルＦ１における、単位データＦ１−１，Ｆ１−２，……，Ｆ１−ｎのそれぞれについて、間引き処理ａをすることにより生成した単位データを、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎと表し、間引き処理ｂをすることにより生成した単位データを、単位データＦ１−ｂ１，Ｆ１−ｂ２，……，Ｆ１−ｂｎと表した。
【００１９】
図６は、このようにして生成した単位データの各々について、サーバ３０に格納した状態を示す概念図である。個々の単位データには、単位データを特定するための名前（識別番号）と、当該単位データのデータ量をあわせて示した。本実施形態において単位データは１秒あたりのデータに対応するから、個々の単位データのデータ量は、ネットワーク２０を経由して送信する際のビットレートに相当することになる。
【００２０】
図６に示すように、サーバ３０は、個々の単位データについて、映像ファイルの先頭から終点に向かう順に格納していく。このため、図６において、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生（デコード）処理すると、一の映像音声の再生が行われることになる。また、単位データＦ１−ａ１と単位データＦ１−ｂ１とは、データ量、すなわち再生した際の映像や音声の品質は違うものの、その内容は同一である。
このため、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生処理した場合であっても、単位データＦ１−ａ１を単位データＦ１−ｂ１に置き換えて、単位データＦ１−ｂ１，Ｆ１−ａ２，……，Ｆ１−ａｎの順で再生処理した場合であっても、得られる映像音声の品質は異なるものの、その内容は同一である。
【００２１】
以上は、映像ファイルＦ１に対し、間引きパターンａ，ｂ，……、で間引き処理を行った場合の内容を説明したが、映像ファイルＦ１と同様にして映像ファイルＦ２，Ｆ３，……、についても、それぞれ間引きパターンａ，ｂ，……、により間引き処理を行っていく。そして、サーバ３０は、生成した単位データについて、図６に示すようにして、映像ファイルの先頭から終点に向かう順に格納していく。
図６において、個々の単位データは、映像音声（コンテンツ）の１秒分のデータに相当し、コンテンツ開始からの時間順に格納されている点では同じである。このため、図６において、縦軸位置を同じに示した単位データＦ１−ａ１，Ｆ１−ｂ２，……，Ｆ２−ａ１，Ｆ２−ｂ１，……、は、ビットレートは異なるものの、再生処理をして得られるコンテンツ（映像）の内容はほとんど同じものになる。
【００２２】
サーバ３０は、このようにして個々の単位データを格納した後、映像ファイルと間引き処理の組み合わせによって一義に決められる単位データ群（たとえば、単位データＦ１−ａ１，Ｆ１−ａ２，……，Ｆ１−ａｎのデータ群）ごとにビットレートの平均値を算出する。そして、ビットレートの平均値の低いほうから順に、インデックス番号を付しておく（図６参照）。
【００２３】
（３）管理テーブルの作成（図２：ステップＳａ３）
その後、サーバ３０は、インデックス番号の若い順、すなわち、平均ビットレートが低い順に並べ替えを行い管理テーブルを作成する。図７は、管理テーブルの内容を図示したものである。従来のデータ送信システムにおいては、平均ビットレートの値をもとに、データ送信時のビットレート制御を行っていた。このため、一時的にビットレートが大きく／小さく変化する現象を検知することができず、ネットワーク２０における諸問題（データ輻輳やパケットロス等）が生じることとなっていたのは上述したとおりである。
【００２４】
（４）動的管理テーブルの作成（図２：ステップＳａ４）
次にサーバ３０は、本実施形態の特徴である動的管理テーブルを生成する。動的管理テーブルは、映像音声データの送信開始時（映像音声データの再生開始時に相当）から単位時間（本実施形態では１秒）ごとに生成（更新）されるテーブルである。
【００２５】
図８は、映像音声データの再生開始時点（映像音声データを送信するときは送信開始時点に相当）を０秒としたときの、コンテンツ開始から０秒目と、１秒経過時点における動的管理テーブルの内容を示したものである。
ここで、０秒目における動的管理テーブルは、０秒〜１秒に相当する単位データ（図６における単位データＦ１−ａ１，Ｆ１−ｂ１，……，Ｆ２−ａ１，Ｆ２−ｂ１，……）のビットレートが低い順に並び替えたものである。また、１秒経過後における動的管理テーブルは、コンテンツ開始から１秒〜２秒に相当する単位データ（図６における単位データＦ１−ａ１，Ｆ１−ｂ１，……，Ｆ２−ａ１，Ｆ２−ｂ１，……）のビットレートが低い順に並び替えたものである。
【００２６】
図８に示されるように、動的管理テーブルの並び順は、インデックス番号、すなわち、平均ビットレートの順番とは無関係であり、その時点における単位データのビットレートの低い順に並べたものである。このため、ある単位データが一時的にビットレートが高く／低くなるような場合であっても、その内容が動的管理テーブルには忠実に反映されることになるのである。
以上が図２のフローチャートの内容説明である。
【００２７】
このようにして生成される動的管理テーブルの内容に基づいて、サーバ３０は、ユーザ端末１０に映像音声データを送信する。
図９は、サーバ３０が映像音声データを送信する際の動作の内容を示すフローチャートである。
ユーザ端末１０に映像音声データの送信を開始する際、サーバ３０は、はじめにネットワーク２０の帯域について検知してビットレートの上限値を判別する（ステップＳｂ１）。なお、ネットワーク２０の帯域を検知したり、ビットレートの上限値を判別するためのプログラムは予めサーバ３０にインストールされている。
【００２８】
次にサーバ３０は、該時点（ここでは映像音声データの再生開始時点）における動的管理テーブルを生成する（ステップＳｂ２）。この時点の動的管理テーブルは、映像音声データの再生開始時点における単位データについて、データ量（ビットレート値）が小さい順に並べたテーブルに相当する。サーバ３０は、判別したビットレート上限値に内輪で最も近いビットレートの単位データを、動的管理テーブルの内容から判断し、送信データとして決定する（ステップＳｂ３）。
【００２９】
図８に例示する動的管理テーブルを用いて説明する。図８において左側のテーブルが、映像音声データ再生開始時（データ送信開始時）の動的管理テーブルである。ネットワーク２０のビットレート上限値が２７０００（ｂｐｓ）であるとすると、サーバ３０は、２７０００（ｂｐｓ）の内輪で一番近い、インデックス番号００３の単位データＦ１−ｂ１を、送信データとして決定する。その後、サーバ３０は、このようにして決定した送信データを、実際にユーザ端末１０に送信する（図９：ステップＳｂ４）。
【００３０】
以上は、映像音声データの再生開示時（データ送信開始時）におけるサーバ３０の動作内容であったが、その後も、サーバ３０は所定時間（１秒）ごとに、ネットワーク２０の帯域を検知する（ステップＳｂ１）。そして、動的管理テーブルの内容を生成（更新）していく（ステップＳｂ２）。たとえば、映像音声データを送信開始後１秒の時点であれば、サーバ３０は、映像音声データの再生開始から１秒経過時点における単位データについて、データ量（ビットレート値）を小さい順に並べかえをして動的管理テーブルの内容を更新する。この後の処理は同様であり、サーバ３０は、判別したビットレート上限値に内輪で最も近いビットレートの単位データを、更新した動的管理テーブルの内容から判断し、送信データとして決定する（ステップＳｂ３）。そしてユーザ端末１０に送信する（ステップＳｂ４）。
【００３１】
図８に例示する動的管理テーブルを用いて説明する。図８において右側のテーブルが、映像音声データ再生開始から１秒経過後（データ送信開始から１秒後）の動的管理テーブルである。ここで、ネットワーク２０のビットレート上限値が２７０００（ｂｐｓ）であるとすると、サーバ３０は、２７０００（ｂｐｓ）の内輪で一番近い、インデックス番号００２の単位データＦ２−ａ２を、送信データとして決定することになる。
【００３２】
その後も、サーバ３０は同様の制御を繰り返し、映像音声データを送信していく。１秒ごとに、動的管理テーブルの内容は更新され、その時点における単位データのデータレートの低い順に並べ替えが行われることになる。このため、ネットワーク２０のビットレート上限値に内輪で最も近い単位データについて迅速に見つけ出すことができるように図られている。
【００３３】
以上説明したように、本実施形態によれば、ネットワーク２０を経由し、単位データにより構成される映像音声データ（ストリームデータ）を送信するにあたり、送信する単位データの候補として、圧縮率（データ量）が異なるものを予め用意しておく。そして、ネットワーク２０の帯域を検知して判断したビットレートの上限値について、内輪で最も近い単位データを送信するようにするから、ネットワーク２０を経由するデータ通信は常に正常に行われ、従来に問題となっていた、データ輻輳やパケットロス等の問題は生じない。
【００３４】
なお上述した各実施形態の内容は、あくまで一例であり、任意に変形を加えることができる。以下に変形例のいくつかを示す。
サーバ３０には、各々の単位データに係るデータ量（ビットレート）の情報が記憶されてさえいれば、ネットワーク２０の帯域に適した単位データを送信するという、本発明の効果を奏することができる。このため、単位データそのものをサーバ３０内に格納しておき、随時読み出してデータ送信を行ってもよいし、単位データそのものはサーバ３０内に格納することなく、データ送信時に随時生成する構成をとってもよい。
【００３５】
また、本発明に係るプログラムのインストール方法は任意である。上述実施形態においては、予めサーバ３０にインストールしている場合を想定したが、プログラムの内容を記憶した記憶媒体（フロッピーディスクやＣＤ−ＲＯＭ等）を介して、サーバ３０にインストールしてもよい。また、ネットワーク２０やその他の網を介してインストールする、いわゆるネット配信を利用する形態であってもよい。
【００３６】
【発明の効果】
以上説明したように、本発明によれば、ネットワークの帯域に応じた映像音声データの送信を問題なく行うことができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態に係るデータ送信システム１００の構成図である。
【図２】 同データ送信システム１００のサーバ３０が各種テーブルを作成する手順を示すフローチャートである。
【図３】 同サーバ３０が映像ファイルを作成する処理内容を示す概念図である。
【図４】 同サーバ３０が行う間引き処理の内容を示す概念図である。
【図５】 同サーバ３０が作成した映像ファイルの内容を説明するための図である。
【図６】 同サーバ３０に単位データが格納された状態を示す概念図である。
【図７】 同サーバ３０に格納される管理テーブルの内容を示す図である。
【図８】 同サーバ３０に格納される動的管理テーブルの内容を示す図である。
【図９】 同サーバ３０の動作内容を示すフローチャートである。
【符号の説明】
１０……ユーザ端末、２０……ネットワーク、
３０……サーバ、１００……データ送信システム。
Claims (5)
- ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する記憶部と、
前記ネットワークの帯域を検知する検知部と、
前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する制御部と
を有することを特徴とするサーバ。 - 請求項１に記載のサーバにおいて、
前記記憶部は、前記映像音声データの再生経過時が同じ分割データに係るビットレートについて並べた管理テーブルであって、前記一定時間ごとにビットレートの低い／高い順に内容が更新される管理テーブルを記憶し、
前記制御部は、前記管理テーブルにおけるビットレートの値のうち、検知した帯域が指定するビットレート上限値以下であって当該上限値に一番近いものを送信レートとして決定すること
を特徴とするサーバ。 - ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する過程と、
前記ネットワークの帯域を検知する過程と、
前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する過程と
を有することを特徴とする送信レート制御方法。 - サーバを、
ネットワークを経由して送信する映像音声データを異なる圧縮率で圧縮するとともに、圧縮したデータの各々を当該映像音声データの再生開始時から一定時間ごとに互いに分割し、当該分割により生成される分割データのビットレートをそれぞれ記憶する手段と、
前記ネットワークの帯域を検知する手段と、
前記映像音声データの再生経過時が同じ分割データに係るビットレートのうち、検知した帯域以下のものを送信レートとして決定する手段と
して機能させることを特徴とするプログラム。 - 請求項４に記載のプログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003001217A JP3976191B2 (ja) | 2003-01-07 | 2003-01-07 | サーバ、送信レート制御方法、プログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003001217A JP3976191B2 (ja) | 2003-01-07 | 2003-01-07 | サーバ、送信レート制御方法、プログラムおよび記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004215074A JP2004215074A (ja) | 2004-07-29 |
| JP3976191B2 true JP3976191B2 (ja) | 2007-09-12 |
Family
ID=32819297
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003001217A Expired - Fee Related JP3976191B2 (ja) | 2003-01-07 | 2003-01-07 | サーバ、送信レート制御方法、プログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3976191B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009117963A (ja) * | 2007-11-02 | 2009-05-28 | Panasonic Corp | 通信端末装置および情報表示方法 |
| JP5213130B2 (ja) * | 2009-08-07 | 2013-06-19 | 日立コンシューマエレクトロニクス株式会社 | データ配信システム、切替装置及びデータ配信方法 |
| KR101750049B1 (ko) | 2009-11-13 | 2017-06-22 | 삼성전자주식회사 | 적응적인 스트리밍 방법 및 장치 |
| KR101786051B1 (ko) | 2009-11-13 | 2017-10-16 | 삼성전자 주식회사 | 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치 |
| KR101777347B1 (ko) * | 2009-11-13 | 2017-09-11 | 삼성전자주식회사 | 부분화에 기초한 적응적인 스트리밍 방법 및 장치 |
| KR101750048B1 (ko) | 2009-11-13 | 2017-07-03 | 삼성전자주식회사 | 변속 재생 서비스 제공 방법 및 장치 |
| KR101737084B1 (ko) | 2009-12-07 | 2017-05-17 | 삼성전자주식회사 | 메인 콘텐트에 다른 콘텐트를 삽입하여 스트리밍하는 방법 및 장치 |
| KR101777348B1 (ko) | 2010-02-23 | 2017-09-11 | 삼성전자주식회사 | 데이터 전송 방법 및 장치와 데이터 수신 방법 및 장치 |
| EP2525587B1 (en) * | 2011-05-17 | 2017-07-05 | Alcatel Lucent | Method for streaming video content, node in a network for monitoring video content streaming |
| JP6289103B2 (ja) * | 2014-01-07 | 2018-03-07 | キヤノン株式会社 | 画像処理装置及びその制御方法、並びに、プログラム |
-
2003
- 2003-01-07 JP JP2003001217A patent/JP3976191B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004215074A (ja) | 2004-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101868280B1 (ko) | 정보 처리 장치, 정보 처리 방법 및 컴퓨터 판독 가능한 기록 매체 | |
| JP5288710B2 (ja) | マルチメディアデータを記録した情報保存媒体、その再生方法及び再生装置 | |
| KR101510822B1 (ko) | 적응적 트릭 플레이 스트리밍 | |
| JP5401464B2 (ja) | 重要度基盤のリッチメディア提供システム及び方法と、これに適用されるサーバー | |
| WO2013008867A1 (ja) | 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体 | |
| JP2004112789A (ja) | マルチメディアストリーミング装置及びその方法 | |
| JP2003114845A (ja) | メディア変換方法およびメディア変換装置 | |
| JP2007295038A (ja) | 動画再生装置及び方法 | |
| JP3976191B2 (ja) | サーバ、送信レート制御方法、プログラムおよび記録媒体 | |
| WO2014112186A1 (ja) | コンテンツサーバおよびコンテンツ配信方法 | |
| KR20050087654A (ko) | 멀티미디어 데이터를 기록한 정보저장매체, 그 재생방법및 재생장치 | |
| JP4526294B2 (ja) | ストリームデータ送信装置、受信装置、プログラムを記録した記録媒体、およびシステム | |
| WO2014171385A1 (ja) | サーバ装置、コンテンツ提供方法及びコンピュータプログラム | |
| JP4750759B2 (ja) | 映像音声再生装置 | |
| JP2014131307A (ja) | 情報処理装置、情報処理方法およびプログラム | |
| JP5219122B2 (ja) | 電子機器 | |
| US7236685B2 (en) | Reproduction speed conversion apparatus | |
| JP2016040919A (ja) | 情報処理装置、情報処理方法およびプログラム | |
| US20240086451A1 (en) | Information processing apparatus, reception apparatus, information processing method, and storage medium | |
| JP4441572B2 (ja) | 記録装置 | |
| JP2022039452A (ja) | 受信端末、配信サーバ、受信方法及び受信プログラム | |
| JP2009060353A (ja) | コンテンツ配信装置、及び移動端末装置、並びにコンテンツ配信システム、コンテンツ配信方法、コンテンツ受信方法、及びコンテンツ配信プログラム | |
| JP2006171444A (ja) | オーディオ再生システム | |
| JP2005027010A (ja) | Ａｖサーバ、ａｖコンテンツ再生装置およびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050407 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061212 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070213 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070612 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070614 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100629 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100629 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110629 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120629 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120629 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130629 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |