JP3860957B2 - マルチメディアデータの送出装置 - Google Patents
マルチメディアデータの送出装置 Download PDFInfo
- Publication number
- JP3860957B2 JP3860957B2 JP2000263586A JP2000263586A JP3860957B2 JP 3860957 B2 JP3860957 B2 JP 3860957B2 JP 2000263586 A JP2000263586 A JP 2000263586A JP 2000263586 A JP2000263586 A JP 2000263586A JP 3860957 B2 JP3860957 B2 JP 3860957B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- multimedia
- still image
- multimedia data
- bit rate
- 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
Landscapes
- Information Transfer Between Computers (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、マルチメディアデータの送出装置に係り、特に、映像、音声等のマルチメディアデータをサーバ計算機側からネットワークを介して視聴者端末側に送信する際の処理の高効率化を図ることがではるマルチメディアデータの送出装置に関する。
【０００２】
【従来の技術】
一般に、静止画、動画像、音声等のマルチメディアデータは、これらをコンピュータ上で扱うために、それらのデータを一旦符号化する必要がある。データを符号化する技術には、様々なものが存在し、用途に応じて適当なものが用いられる。この技術には大きく分けて、データを圧縮をするものと非圧縮のものとがある。圧縮を伴った符号化を行うと、データのサイズが大幅に少なくなる。圧縮を伴う符号化技術の例を挙げると、静止画を符号化する技術として、ＪＰＥＧ（Joint Photographic Experts Group）が知られており、また、動画の映像や音声を符号化する技術としてＭＰＥＧ（Moving Picture Experts Group）が知られている。
【０００３】
また、コンピュータ同志が情報を交換するために、コンピュータネットワーク技術が用いられる。屋内など限られた大きさの環境では、ＬＡＮ（Local Area Network）と呼ばれるネットワーク技術が用いられることが多い。また、小さなネットワークをお互いに接続することによって、全世界レベルの大きさのネットワークが作られた。このネットワークは、「インターネット」と呼ばれ、多くのユーザによって利用されており、これらのネットワークの上でデータを交換することを可能にする様々なアプリケーションが動作している。マルチメディアデータをネットワーク上で送信する技術を用いたアプリケーションとして、例えば、ＶＯＤ(Video On Demand）と呼ばれる技術が知られている。ＶＯＤは、符号化した映像データを蓄積したサーバに対して視聴者端末が映像データの送信要求を出すと、サーバが視聴者端末に向けて映像配信のサービスを行うアプリケーションである。ＶＯＤは、ＬＡＮ環境でも動作可能であるし、インターネット環境でも動作可能である。
【０００４】
インターネット、ＬＡＮは、共にネットワークの帯域幅、すなわち、単位時間当たりにどの程度の量のデータを通すことができるかが、それぞれの環境では決まっており、ネットワークによって映像配信のためのサービスの質が決まってしまう。
【０００５】
【発明が解決しようとする課題】
ところで、あるＶＯＤサーバが異なるネットワークに向けてサービスを行う場合、そのＶＯＤサーバは、ネットワーク毎に異なるビットレートで映像等のマルチメディアデータを符号化して送信しなければならないが、複数のビットレートで映像等のマルチメディアデータを符号化して保存しておくのは不便である。しかし、１種類の符号化データを用いてＶＯＤサービスを行うと、ネットワーク環境の帯域幅以上のビットレートの映像データを流したときに、視聴者端末上で再生される映像や音声が非常に乱れたものとなる可能性がある。なぜなら、映像や音声のデータは、あるビットレートで符号化してあるにもかかわらず、それより低いビットレートで再生がなされると、意図していたものよりより遅い映像や音声になってしまうからである。また、このようなことが続くと、いつかサーバ側のバッファがオーバーフローしてしまい、その結果映像や音声の連続性が損なわれてしまうことになる。
【０００６】
前述したような問題を解決することができる従来技術の１つとして、符号化の階層化という技術が知られている。階層符号化に関する従来技術として、例えば、「ＭＰＥＧ−４のすべて」（工業調査会、三木編著、Ｐ．１１９、９行目〜Ｐ．１２０、２行目）に詳しく説明されている技術が知られている。符号化を階層化をしておくことにより、符号化されたデータは、その一部分だけの再生が可能となる。ＶＯＤサーバに蓄積されるマルチメディアデータが階層化した形で符号化されていると、ＶＯＤサーバは、ネットワークの帯域幅に応じて一部分だけを送信すればよいことになる。そうすると、視聴者端末は、ネットワーク環境に応じて、ビットレートの高低にかかわらず受信したデータを再生することが可能となり、ネットワークの帯域幅に応じて最大限の品質で再生することが可能となる。
【０００７】
しかし、前述した従来技術は、ＶＯＤサーバに蓄積するマルチメディアデータを予め階層化した形で符号化する必要があるが、階層化を行うことができる符号化装置が一般的なものに比較して高価であり、また、符号化したマルチメディアデータのファイルが複数できるため、管理も難しくなるという問題点を有している。
【０００８】
本発明の目的は、前述した従来技術の問題点を解決し、符号化を階層化することなく、ネットワーク環境の帯域幅に応じて、送信するマルチメディアデータの送信ビットレートを動的に調整することができるマルチメディアデータの送出装置を提供することにある。
【０００９】
【課題を解決するための手段】
本発明によれば前記目的は、マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記シナリオ情報に基づき再生されるマルチメディアデータを構成するデータのうち、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるビットレートで送信可能な第１のデータ以外の他のデータである第２のデータを送信し、該第２のデータの送信が完了するまで、前記第１のデータを保持しておき、前記第２のデータの送信が終了した後、保持していた前記第１のデータをリアルタイムに送信することにより達成される。
【００１０】
また、前記目的は、マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記映像データのフレームを落とし、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるようにして前記各データを送信することにより達成される。
【００１１】
【発明の実施の形態】
以下、本発明によるマルチメディアデータの送出装置の一実施形態を図面により詳細に説明する。
【００１２】
図１は本発明の一実施形態によるマルチメディアデータ送出装置のハードウェア構成を示すブロック図、図２は本発明によるマルチメディアデータ送出装置が適用されるネットワーク構成を示すブロック図、図３は本発明の一実施形態によるマルチメディアデータ送出装置の機能構成を示すブロック図、図４はマルチメディア属性情報の構造を説明する図、図５はマルチメディア属性情報を格納したテーブルの内容を示す図、図６はネットワーク情報を格納したテーブルの内容を示す図、図７は要求バッファに格納される情報内容を説明する図、図８は第１のバッファにテーブルとして格納されるシナリオ情報の内容を説明する図、図９は第２のバッファにテーブルとして格納される情報内容を説明する図である。図１〜図９において、１０はマルチメディアデータ送出装置、１１はＣＰＵ、１２はキーボード、１３はディスプレイ、１４はネットワークインタフェース、１５はバス、１６は主メモリ、１６１は送出エンジン、１６２は要求バッファ、１６３は第１のバッファ、１６４は第２のバッファ、１７はハードディスク、１７１はマルチメディア属性情報、１７２はネットワーク情報、１７３はマルチメディアデータ、２０はインターネット、３０、４０、６０き利用者端末、５０はＬＡＮである。
【００１３】
本発明によるマルチメディアデータ送出装置が適用されるネットワーク環境は、図２にその例を示すように、マルチメディア送出装置１０が、インターネット２０を介して複数の利用者端末３０、４０、．．．に接続可能であり、また、ＬＡＮ５０を介して複数の利用者端末６０、．．．に接続可能であるようなネットワーク環境である。このようなネットワーク環境において、マルチメディア送出装置１０は、要求されたマルチメディアデータを利用者端末３０、４０、６０等に対して送出する。具体的な手順としては、まず、利用者端末３０が、マルチメディアデータ送出装置１０に対してマルチメディアデータの送信を要求し、これに対してマルチメディア送出装置１０が、ハードディスク内に保持しているマルチメディアデータを検索し、それを利用者端末３０に送出するという手順で行われる。
【００１４】
マルチメディアデータは、単なるテキストデータや静止画データだけではなく、音声、映像といったリアルタイム性を要するデータをも含んでいる。以下の説明において、マルチメディアデータは、静止画、音声、映像の３種類のデータを含むものとする。すでに説明したように、音声、映像といったリアルタイム性を要するデータは、ネットワークの帯域幅が小さい場合、利用者端末３０上で再生する際に問題が起こる可能性がある。音声データや映像データは、一定のビットレートで再生されないと、正しい聞こえ方、見え方をしないからである。
【００１５】
本発明のマルチメディアデータ送出装置１０は、この問題を解決するために、マルチメディアデータの送出の際に利用者端末３０までのインターネット２０上の帯域幅をある程度検知し、それに基づいてマルチメディアデータ内の静止画、音声、映像のデータをデータのある区間内で順序を変えて送信したり、一部だけを送信したりする。順序を変える理由は、マルチメディアデータ内の一部のデータを他のデータに先立って利用者端末３０にダウンロードさせるためである。このようにすることにより、残りのデータは、少ない帯域幅でリアルタイムに送信することが可能となる。この結果、利用者端末３０は、ダウンロードによる待ち時間も少なく、かつ、マルチメディアデータを乱れることなく視聴させることが可能となる。また、マルチメディアデータの一部だけ送信する理由は、マルチメディアデータのビットレートを下げるためである。具体的には、映像データのコマを落とすことである。映像データは、多少コマが落とされても情報として足りる場合が多く、これにより、少ない帯域幅でも利用者端末３０は、待ち時間を最大限に低減させてマルチメディアデータを正しい速さで再生することが可能となる。
【００１６】
図１に示すように、マルチメディアデータ送出装置１０は、ＣＰＵ１１、キーボード１２、ディスプレイ１３、ネットワークインタフェース１４、バス１５、主メモリ１６、及び、ハードディスク１７を備えて構成されている。管理者は、キーボード１２、ディスプレイ１３を使用してマルチメディアデータ送出装置１０を操作する。ネットワークインタフェース１４は、インターネット２０、ＬＡＮ５０からのデータを受信し、あるいは、インターネット２０、ＬＡＮ５０に対してデータを送信する。ＣＰＵ１１は、バス１５を介して主メモリ１６内のプログラムを起動し、主メモリ１６内の各プログラムは、バス１５を介してハードディスク１７内の情報にアクセスする。主メモリ１６内には、送出エンジン１６１、要求バッファ１６２、第１のバッファ１６３、第２のバッファ１６４が構成されている。また、ハードディスク１７内には、マルチメディア属性情報１７１、ネットワーク情報１７２、マルチメディアデータ１７３が格納されている。なお、これらの働きについては後述する。
【００１７】
マルチメディアデータ送出装置１０の機能は、図３に示すようなものである。そして、この機能は、図１により説明した主メモリ１６内に設けられる要求バッファ１６２からの要求に従って、ハードディスク１７内のマルチメディア属性情報１７１とネットワーク情報１７２とから必要な情報を読み出して第１のバッファ１６３に格納し、また、モード種別等に従って、送信するデータの内容と順序とを第２のバッファ１６４に格納し、この第２のバッファ１６４の内容に従って、マルチメディアデータ１７３を読み出して、送信エンジン１６１からネットワークインタフェース１４、インターネット２０またはＬＡＮ５０を介して利用者端末にマルチメディアデータを送信するものである。
【００１８】
以下、図３を参照して、マルチメディア送出装置１０が、少ない帯域幅のネットワークを介して効率よくマルチメディアデータを送出する方法について説明する。
【００１９】
ここで、利用者端末３０でマルチメディアデータを再生する方法として、「リアルタイム」モードと「画質優先」モードとの２種類のモードを与えることとする。「リアルタイム」モードは、マルチメディアデータができるだけ時間通りに再生されることを送出装置に対して要求するモードであり、例えば、マルチメディアデータが全部で３０秒の内容だとすると、ネットワークの帯域幅にかかわらず再生が３０秒で終了するように送出することを要求するモードである。一方、「画質優先」モードは、ネットワークの帯域幅が小さい場合、リアルタイム性を犠牲にし、画質を落とさないことを優先するモードである。なお、このモードは、リアルタイム性を犠牲にするが、ある区間単位では映像、音声が正しく連続的に再生されることを要求するものである。
【００２０】
図３において、ネットワークインタフェース１４は、インターネットからマルチメディアデータの送信要求を受信すると、受信した要求を要求バッファ１６２に渡す。このとき、図７に示すように、区間指定１６２０１、モード種別１６２０２、利用者端末のＩＰアドレスである端末アドレス１６２０３の３つが指定される。区間指定１６２０１は、利用者端末が要求しているデータ区間であり、具体的には、マルチメディアデータの先頭を０秒として何秒後までのデータが欲しいかが指定され、例えば、２５秒目から３０秒までのデータが欲しい場合、その指定がなされる。モード種別１６２０２は、すでに説明した再生モードの種別である。端末アドレス１６２０３は、要求を行った利用者端末のＩＰアドレスである。
【００２１】
要求バッファ１６２内にこれらの内容が指定されて格納されると、次に、マルチメディア属性情報１７１がアクセスされる。ここで、図４を用いてマルチメディア属性情報１７１の構造を説明する。マルチメディアデータは、予め意味のある単位で区間分けされている。例えば、１つの静止画データが表示される時間を１つの区間として区分けされている。これを示したのが図４の１７１０４であり、それぞれの区間の中には、静止画、音声、映像データの属性データが格納されている。具体的には、静止画のバイト数１７１０１、音声データのビットレート１７１０２、映像データのビットレート及びコマ情報１７１０３等である。マルチメディアデータ送出装置１０は、これらの属性情報を用いることにより、送出順序を変えたり送出データを選択したりすることが可能となる。マルチメディア属性情報１７１は、前述したような構造を持つことにより、マルチメディアデータの区間情報と各データの属性情報とを格納することができる。なお、区間の分け方は、前述のように１つの静止画データが表示される時間ではなく、動画である映像データの性質等の状況が大きく変わるポイントによってもよい。
【００２２】
ここで、再度、図３を参照すると、前述した手順により、要求バッファ１６２内の再生区間に該当する部分である１つの区間１７１０４がマルチメディア属性情報１７１から取り出しして、第１のバッファ１６３に格納されたことになる。
【００２３】
一方、ネットワーク情報１７２には、マルチメディアデータを送信する端末のＩＰアドレスとその端末へ接続されるネットワークの帯域幅とが対応付けて格納されている。要求バッファ１６２内に保持されたＩＰアドレスとネットワーク情報１７２とにより、送出先までのネットワークの帯域幅を得ることができ、これが第１のバッファ１６３に格納される。また、要求バッファ１６２に格納されていたモード種別も、第１のバッファ１６３に格納される。前述の結果、第１のバッファ１６３には、指定された区間のマルチメディア属性情報と、利用者端末までのネットワークの帯域幅の情報と、モード種別の情報とが格納されたことになる。次に、これらの情報を用いて、実際に送信されるべきデータの内容とその順序が決められ、その結果が第２のバッファ１６４に格納される。この送信内容に従って、マルチメディアデータ１７３が取り出され、送信エンジン１６１によりネットワークインタフェース１４を介してインターネット２０等のネットワークに送信される。
【００２４】
第２のバッファ１６４に格納される送信内容をどのようにして決定するかは、モード種別によって大きく異なる。モード種別が「リアルタイム」モードの場合、できるだけ実時間で送信することが要求されているので、ネットワークの帯域幅が映像データの全てを実時間で送信することができない大きさの場合、映像データのコマ落としが行われる。そして、コマ落としを行った結果、映像データの送信ビットレートがネットワークの帯域幅を下回る程度までとなるようにする。但し、映像データがＭＰＥＧのようなフレーム（コマと同義）間補償を行う方式の圧縮技術を用いて作られている場合、コマ落としの方法によっては、利用者端末内のデコーダがうまく再生できない場合がある。その場合、第１のバッファ１６３内にあるアクセスポイントの情報を用いて、アクセスポイントのデータを優先的に送信するようにする。
【００２５】
一方、モード種別が「画質優先」モードの場合、映像のコマ落としを行わない。その代わりに、ネットワークの帯域幅を超えないようにマルチメディアデータ内の各データを順番に送出する。例えば、リアルタイム性の必要ない静止画データを先に送出する。そして、残りの映像データと音声データとを同時に送信したときにネットワークの帯域幅を下回るか否かをチェックし、下回る場合、残りを同時に送信し、そうでない場合、映像データあるいは音声データを先に送信し、最後に残りを送信する。
【００２６】
利用者端末は、静止画データについてそのデータが到着次第それを画面に表示する。これにより、利用者端末は、ネットワークの帯域幅不足による遅れを生じさせることなく、時間通りにマルチメディアデータを再生することができる。一方、利用者端末は、映像データや音声データのどちらか片方のデータが到着した場合、そのデータをバッファに一時的に蓄積しておき、残りのデータが到着した時点で同期させながら再生する。これにより、利用者端末は、映像と音声とを同時に再生することができ、ネットワークの帯域幅不足による品質の低下を防止してこられのデータを再生することができる。このアルゴリズムの詳細については、後述する。
【００２７】
前述した説明から判るように、本発明の実施形態によるマルチメディアデータ送出装置１０は、少ない帯域幅のネットワークの場合でも、利用者端末に最大限効率よくマルチメディアデータを送出することが可能である。
【００２８】
次に、図５に示すテーブル例を参照して、マルチメディア属性情報１７１の内容について説明する。マルチメディア属性情報１７１は、マルチメディアデータ内の映像データ、音声データ、静止画データの属性情報が格納されているテーブルである。図５において、１７１５２の列は、マルチメディアデータ内の映像データの各フレームの時刻を示している。図には、幾つかのコマを纏めた間隔を意味区間と定め、これらの意味区間を横線で区切って示している。１７１５１の列が前記した各意味区間の範囲を示している。この意味区間は、この例では、マルチメディアデータの再生によって映像データと同時に表示される静止画データの変わり目を区間の変わり目としている。１７１５６の列には、意味区間内で表示される静止画データのバイト数が格納されている。１７１５３の列には、各意味区間における映像データの平均ビットレートが格納されている。１７１５４の列には、映像データのフレームのうちアクセスポイントとなるフレームが示されている。アクセスポイントとは、１つのフレームのデータだけを利用者端末に送出した場合にも、利用者端末上で正しく表示できるフレームを意味する。ＭＰＥＧ等の動き補償技術を用いて符号化を行った映像データは、任意のフレームを利用者端末に送出しても、そのフレームを再生できるとは限らず、前述のようなアクセスポイントが存在し、前述したように、ＭＰＥＧ等により符号化された映像データの場合、アクセスポイントからのデータを送信する。１７１５５の列には、意味区間内で再生される音声データの平均ビットレートが格納されている。
【００２９】
マルチメディア属性情報１７１は、全てマルチメディアデータ１７３そのものから得ることができる。しかし、マルチメディアデータを送信する前に、マルチメディアデータの属性情報に基づいてデータの選択の処理をリアルタイムに行う必要がある。マルチメディア属性情報を前もって作成しておくとにより、送信しながらマルチメディアデータの選択の処理を行うことが容易となる。
【００３０】
次に、図６に示すテーブルの例を参照して、ネットワーク情報１７２の内容について説明する。ネットワーク情報１７２は、マルチメディア送出装置１０がデータを送出する相手先である利用者端末３０へのネットワークの帯域幅の情報を格納している。図６において、１７２０１の列には、送出先の利用者端末のＩＰアドレスが格納されている。この例では、１つ１つの数字が複数のＩＰアドレスをまとめて表現している。例えば、図示の「１２３．４５６．７８９．０００」は、「１２３．４５６．７８９」で始まるアドレスを全て表している。１７２０２の列は、それぞれのＩＰアドレス群に対応したネットワークの帯域幅を示している。このテーブルを用いることにより、送出先の利用者端末を接続するネットワークの帯域幅を得ることが可能となる。
【００３１】
次に、図８に示すテーブルの例を参照して、第１のバッファ１６３の内容について説明する。図８において、１６３０１〜１６３０６の各列は、マルチメディア属性情報１７１内のある１つの意味区間のデータを取り出した内容である。また、１６３０７の列には、要求バッファ１６２に格納されていた再生モード種別が格納される。第１のバッファ１６３には、利用者端末が要求した意味区間単位のマルチメディアデータに関わる情報がシナリオ情報として一時的に格納される。そして、要求されるマルチメディアデータを構成する複数の意味区間のデータが意味区間毎に図８に示すようなテーブルとして第１のバッファに格納される。
【００３２】
次に、図９（ａ）を参照して、利用者端末が「リアルタイム」モードを指定した場合における第２バッファ１６４の内容の例について説明する。図９（ａ）において、１６４０１〜１６４０６の各列の２行目以下の各行１６４０６〜１６４１０には、映像データの各フレーム毎の情報が格納されている。列１６４０１には、映像データのフレームが再生される時刻が格納され、列１６４０４には、映像データの各フレームについて、送信するものについて「１」、送信しないものについて「０」が格納されている。これは、ネットワークの帯域幅の条件に照らし合わせた結果、一部のフレームのみが送信され、残りは送信しないと判断した結果である。この映像データの場合、図８に示しているように、アクセスポイントが一部のフレームに限られているため、送信するべきフレームはアクセスポイントのフレームとなっている。列１６４０３は、各時刻における音声データのうち、送信されるものについて「１」が指定されている。図示例の場合、全てのデータを送ることとなる。列１６４０２は、静止画を送信する時刻に関する情報である。静止画データは、図示している意味区間に１つのデータがあり、図示例の場合、この区間が始まってすぐに送信を行ってしまうことを意味している。
【００３３】
次に、図９（ｂ）を参照して、利用者端末が「画質優先」モードを指定した場合における第２のバッファ１６４の内容の例について説明する。「リアルタイム」モードの場合と異なっているのは、ネットワーク帯域幅が小さい場合に各データの送信順序を変えることである。図９（ｂ）において、最も上の第１行１６４５５に「１」が格納されているのは、予めデータを利用者端末に送信をすませておくことを意味する。図示例の場合、列１６４５２の静止画と１６４５４の映像データとについて、この区間に送信するべき内容を、予め送信を非リアルタイムに済ませておくことを意味する。その後、列１６４５３に示すように、音声データのみが時間通りに送信される。
【００３４】
送信エンジン１６１は、前述したような第２のバッファ１６４の内容に従って送信を行うことにより、限られたネットワークの帯域幅の中で有効なマルチメディアデータの送信を行うことが可能となる。
【００３５】
図１０は第１のバッファ１６３の内容により第２のバッファ１６４の内容を決定するアルゴリズムを説明するフローチャート（その１）であり、以下、これについて説明する。ここで説明するフローは、第１のバッファ１６３内に「リアルタイム」モードが指定されている場合の例である。
【００３６】
（１）最初に、ネットワークの帯域幅（図８、１６３０１）の値と、映像、音声、静止画の各データの合計の平均のビットレートとを比較して、通常通りこれらのデータを送信してもネットワークの帯域幅が充分か否かをチェックし、通常通りに送信することが可能な場合、各データを通常通りに送信する（ステップ５１、５６）。
【００３７】
（２）ステップ５１のチェックで、通常通りに送信することができない場合、映像データのコマを落とした場合にネットワークの帯域幅が充分となるか否かを調べ、フレームを落として充分となる場合、映像データから必要なだけのフレームを落として送信を行う。この場合、送信する映像データは、アクセスポイント（図８、１６３０４）の映像データとする（ステップ５２、５７）。
【００３８】
（３）ステップ５２のチェックで、映像データのフレームを落としてもなお、マルチメディアデータのスループットがネットワークの帯域幅を超える場合、映像データとして最初のコマのデータのみを送信してネットワークの帯域幅を超えないか否かを調べ、超えない場合、映像データの最初のフレームのみの送信を行う（ステップ５３、５８）。
【００３９】
（４）ステップ５３のチェックで、映像データの最初のフレームのみを送信してもネットワークの帯域幅を超える場合、リアルタイムに送信することが不可能であるので、この処理を失敗とする（ステップ５５）。
【００４０】
図１１は第１のバッファ１６３の内容により第２のバッファ１６４の内容を決定するアルゴリズムを説明するフローチャート（その２）であり、以下、これについて説明する。ここで説明するフローは、第１のバッファ１６３内に「画質優先」モードが指定されている場合の例である。
【００４１】
（１）最初に、ネットワークの帯域幅（図８、１６３０１）の値と、映像、音声、静止画の各データの合計の平均のビットレートとを比較して、通常通りこれらのデータを送信してもネットワークの帯域幅が充分か否かをチェックし、通常通りに送信することが可能な場合、各データを通常通りに送信する（ステップ６１、６６）。
【００４２】
（２）ステップ６１のチェックで、通常通りに送信することができない場合、静止画データを除いた他のデータを送るとした場合にネットワークの帯域幅が充分となるか否かを調べ、充分となる場合、静止画データを先に送信して、その後に他のデータを通常通りに送信する（ステップ６２、６７）。
【００４３】
（３）ステップ６２のチェックで、静止画データを除いてもネットワークの帯域幅が充分でなかった場合は、静止画データと映像データをと除いた他のデータを送るとした場合にネットワークの帯域幅が充分となるか否かを調べ、充分となる場合、静止画データと映像データとを先に送信してしまい、音声データのみを通常通りに送信する（ステップ６３、６８）。
【００４４】
（４）ステップ６３のチェックで、静止画データと映像データとを先に送信してもネットワークの帯域幅が充分ならない場合、全てのデータを非リアルタイム送信として送信する。この結果、全てのデータは、利用者端末上で一時的にキャッシュされて再生される（ステップ６５）。
【００４５】
前述した図１０に説明したフローにおいて、第１のバッファ１６３の内容が図８に示す通りである場合、このフローによるアルゴリズムを適用して第２のバッファ１６４がどのようになるかについて説明する。
【００４６】
最初に、ステップ５１のチェックで、各データを通常通りに送信すると仮定した平均ビットレートを調べる。図８に示す例の場合、映像データの５フレーム時間に渡る図８に示す区間での２０ＫＢの大きさを持つ静止画の平均ビットレートは、２０×８÷５＝３２ｋｂｐｓとなり、各データを合算した図示区間の平均ビットレートは、２５６＋６４＋３２＝３５２ｋｂｐｓとなる。この値は、ネットワークの帯域幅１６３０１に示される２００ｋｂｐｓを超えている。よって、次に、ステップ５２のチェックで、映像データのフレームを落としてみる。映像データは、各フレーム当たりのバイト数が同じであると仮定すると、フレームを２枚送ると帯域幅を超えないことが判る。すなわち、この場合、映像データの平均ビットレートは、２５６÷５×２＝１０２．４ｋｂｐｓとなり、各データを合算した平均ビットレートは、１０２．４＋６４＋３２＝１９８．４ｋｂｐｓとなる。この値は、ネットワークの帯域幅１６３０１に示される２００ｋｂｐｓ以内に収まるものであり、映像アクセスポイントを１６３０４から得て、映像データに関してはアクセスポイントとして指定されたフレームのみを送信する。このようにして第２のバッファの内容が決定する。
【００４７】
次に、前述した図１１に説明したフローにおいて、第１のバッファ１６３の内容が、図８におけるモード種別が「画質優先」モードとなっている場合について、このフローによるアルゴリズムを適用して第２のバッファ１６４がどのようになるかについて説明する。
【００４８】
最初に、ステップ６１のチェックで、各データを通常通りに送信すると仮定した平均ビットレートを調べる。この場合、前述した場合と同一であり、図示区間の平均ビットレートは３５２ｋｂｐｓとなり、ネットワークの帯域幅１６３０１の２００ｋｂｐｓを超えているので、ステップ６２で静止画データを除いたと仮定して、平均ビットレートを求める。この場合、２５６＋６４＝３２０ｋｂｐｓとなり、これでもネットワークの帯域幅を超えている。次に、ステップ６３のチェックで、静止画データと映像データとを除いたと仮定して平均ビットレートを求めると、音声データのみの６４ｋｂｐｓとなる。この値は、ネットワークの帯域幅を超えていない。従って、静止画データ及び映像データを先に送信して、音声データを時間通りに送信するという結果を得ることができる。
【００４９】
前述で説明したように、図１０、図１１に示したフローによるアルゴリズムを用いることにより、第１のバッファ１６３に格納された意味区間単位の送信要求に対して、ネットワークの帯域幅内で効率よくマルチメディアデータを送信する方法を第２のバッファ１６４に格納することが可能となる。
【００５０】
前述した本発明の実施形態は、本発明を、あるネットワーク環境におけるマルチメディア送出装置に適用したものとして説明したが、本発明は、ネットワーク環境に適用される場合に限られるものではなく、例えば、同一のコンピュータ内で動作するマルチメディアデータ表示アプリケーションに対して、マルチメディアデータをハードディスクなどから読み出し提供する装置にも適用することができる。この場合、前述で説明した本発明の実施形態における利用者端末をマルチメディアデータ表示アプリケーションとし、それとの間に位置するネットワークをコンピュータ内の伝送経路、例えば、バス装置等とすればよい。
【００５１】
また、前述した本発明実施形態におけるマルチメディア送出装置内の処理は、プログラムにより実行させることができ、そのプログラムは、ＦＤ、ＣＤＲＯＭ、ＤＶＤＲＯＭ、ＭＯ等の記録媒体に格納して提供することができる。
【００５２】
前述したように本発明の実施形態によれば、マルチメディアデータを構成する映像データの一部のみ送信したり、マルチメディアデータ内の各データの送信順序を変えることが可能となり、マルチメディア送出装置及び視聴者端末の間のネットワークの帯域幅が少ない場合でも、視聴者端末上で再生表示が乱れることなく、また待ち時間も少なく、高品質のマルチメディアデータの表示を行わせることができる。
【００５３】
【発明の効果】
以上説明したように本発明によれば、ネットワーク環境の帯域幅に応じて、送信するマルチメディアデータの送信ビットレートを動的に調整することができ、視聴者端末上で高品質のマルチメディアデータの表示を行わせることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるマルチメディアデータ送出装置のハードウェア構成を示すブロック図である。
【図２】本発明によるマルチメディアデータ送出装置が適用されるネットワーク構成を示すブロック図である。
【図３】本発明の一実施形態によるマルチメディアデータ送出装置の機能構成を示すブロック図である。
【図４】マルチメディア属性情報の構造を説明する図である。
【図５】マルチメディア属性情報を格納したテーブルの内容を示す図である。
【図６】ネットワーク情報を格納したテーブルの内容を示す図である。
【図７】要求バッファに格納される情報内容を説明する図である。
【図８】第１のバッファにテーブルとして格納される情報内容を説明する図である。
【図９】第２のバッファにテーブルとして格納される情報内容を説明する図である。
【図１０】第１のバッファの内容により第２のバッファの内容を決定するアルゴリズムを説明するフローチャート（その１）である。
【図１１】第１のバッファの内容により第２のバッファの内容を決定するアルゴリズムを説明するフローチャート（その２）である。
【符号の説明】
１０ マルチメディアデータ送出装置
１１ ＣＰＵ
１２ キーボード
１３ ディスプレイ
１４ ネットワークインタフェース
１５ バス
１６ 主メモリ
１６１ 送出エンジン
１６２ 要求バッファ
１６３ 第１のバッファ
１６４ 第２のバッファ
１７ ハードディスク
１７１ マルチメディア属性情報
１７２ ネットワーク情報
１７３ マルチメディアデータ
２０ インターネット
３０、４０、６０ 利用者端末
５０ ＬＡＮ
【発明の属する技術分野】
本発明は、マルチメディアデータの送出装置に係り、特に、映像、音声等のマルチメディアデータをサーバ計算機側からネットワークを介して視聴者端末側に送信する際の処理の高効率化を図ることがではるマルチメディアデータの送出装置に関する。
【０００２】
【従来の技術】
一般に、静止画、動画像、音声等のマルチメディアデータは、これらをコンピュータ上で扱うために、それらのデータを一旦符号化する必要がある。データを符号化する技術には、様々なものが存在し、用途に応じて適当なものが用いられる。この技術には大きく分けて、データを圧縮をするものと非圧縮のものとがある。圧縮を伴った符号化を行うと、データのサイズが大幅に少なくなる。圧縮を伴う符号化技術の例を挙げると、静止画を符号化する技術として、ＪＰＥＧ（Joint Photographic Experts Group）が知られており、また、動画の映像や音声を符号化する技術としてＭＰＥＧ（Moving Picture Experts Group）が知られている。
【０００３】
また、コンピュータ同志が情報を交換するために、コンピュータネットワーク技術が用いられる。屋内など限られた大きさの環境では、ＬＡＮ（Local Area Network）と呼ばれるネットワーク技術が用いられることが多い。また、小さなネットワークをお互いに接続することによって、全世界レベルの大きさのネットワークが作られた。このネットワークは、「インターネット」と呼ばれ、多くのユーザによって利用されており、これらのネットワークの上でデータを交換することを可能にする様々なアプリケーションが動作している。マルチメディアデータをネットワーク上で送信する技術を用いたアプリケーションとして、例えば、ＶＯＤ(Video On Demand）と呼ばれる技術が知られている。ＶＯＤは、符号化した映像データを蓄積したサーバに対して視聴者端末が映像データの送信要求を出すと、サーバが視聴者端末に向けて映像配信のサービスを行うアプリケーションである。ＶＯＤは、ＬＡＮ環境でも動作可能であるし、インターネット環境でも動作可能である。
【０００４】
インターネット、ＬＡＮは、共にネットワークの帯域幅、すなわち、単位時間当たりにどの程度の量のデータを通すことができるかが、それぞれの環境では決まっており、ネットワークによって映像配信のためのサービスの質が決まってしまう。
【０００５】
【発明が解決しようとする課題】
ところで、あるＶＯＤサーバが異なるネットワークに向けてサービスを行う場合、そのＶＯＤサーバは、ネットワーク毎に異なるビットレートで映像等のマルチメディアデータを符号化して送信しなければならないが、複数のビットレートで映像等のマルチメディアデータを符号化して保存しておくのは不便である。しかし、１種類の符号化データを用いてＶＯＤサービスを行うと、ネットワーク環境の帯域幅以上のビットレートの映像データを流したときに、視聴者端末上で再生される映像や音声が非常に乱れたものとなる可能性がある。なぜなら、映像や音声のデータは、あるビットレートで符号化してあるにもかかわらず、それより低いビットレートで再生がなされると、意図していたものよりより遅い映像や音声になってしまうからである。また、このようなことが続くと、いつかサーバ側のバッファがオーバーフローしてしまい、その結果映像や音声の連続性が損なわれてしまうことになる。
【０００６】
前述したような問題を解決することができる従来技術の１つとして、符号化の階層化という技術が知られている。階層符号化に関する従来技術として、例えば、「ＭＰＥＧ−４のすべて」（工業調査会、三木編著、Ｐ．１１９、９行目〜Ｐ．１２０、２行目）に詳しく説明されている技術が知られている。符号化を階層化をしておくことにより、符号化されたデータは、その一部分だけの再生が可能となる。ＶＯＤサーバに蓄積されるマルチメディアデータが階層化した形で符号化されていると、ＶＯＤサーバは、ネットワークの帯域幅に応じて一部分だけを送信すればよいことになる。そうすると、視聴者端末は、ネットワーク環境に応じて、ビットレートの高低にかかわらず受信したデータを再生することが可能となり、ネットワークの帯域幅に応じて最大限の品質で再生することが可能となる。
【０００７】
しかし、前述した従来技術は、ＶＯＤサーバに蓄積するマルチメディアデータを予め階層化した形で符号化する必要があるが、階層化を行うことができる符号化装置が一般的なものに比較して高価であり、また、符号化したマルチメディアデータのファイルが複数できるため、管理も難しくなるという問題点を有している。
【０００８】
本発明の目的は、前述した従来技術の問題点を解決し、符号化を階層化することなく、ネットワーク環境の帯域幅に応じて、送信するマルチメディアデータの送信ビットレートを動的に調整することができるマルチメディアデータの送出装置を提供することにある。
【０００９】
【課題を解決するための手段】
本発明によれば前記目的は、マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記シナリオ情報に基づき再生されるマルチメディアデータを構成するデータのうち、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるビットレートで送信可能な第１のデータ以外の他のデータである第２のデータを送信し、該第２のデータの送信が完了するまで、前記第１のデータを保持しておき、前記第２のデータの送信が終了した後、保持していた前記第１のデータをリアルタイムに送信することにより達成される。
【００１０】
また、前記目的は、マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記映像データのフレームを落とし、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるようにして前記各データを送信することにより達成される。
【００１１】
【発明の実施の形態】
以下、本発明によるマルチメディアデータの送出装置の一実施形態を図面により詳細に説明する。
【００１２】
図１は本発明の一実施形態によるマルチメディアデータ送出装置のハードウェア構成を示すブロック図、図２は本発明によるマルチメディアデータ送出装置が適用されるネットワーク構成を示すブロック図、図３は本発明の一実施形態によるマルチメディアデータ送出装置の機能構成を示すブロック図、図４はマルチメディア属性情報の構造を説明する図、図５はマルチメディア属性情報を格納したテーブルの内容を示す図、図６はネットワーク情報を格納したテーブルの内容を示す図、図７は要求バッファに格納される情報内容を説明する図、図８は第１のバッファにテーブルとして格納されるシナリオ情報の内容を説明する図、図９は第２のバッファにテーブルとして格納される情報内容を説明する図である。図１〜図９において、１０はマルチメディアデータ送出装置、１１はＣＰＵ、１２はキーボード、１３はディスプレイ、１４はネットワークインタフェース、１５はバス、１６は主メモリ、１６１は送出エンジン、１６２は要求バッファ、１６３は第１のバッファ、１６４は第２のバッファ、１７はハードディスク、１７１はマルチメディア属性情報、１７２はネットワーク情報、１７３はマルチメディアデータ、２０はインターネット、３０、４０、６０き利用者端末、５０はＬＡＮである。
【００１３】
本発明によるマルチメディアデータ送出装置が適用されるネットワーク環境は、図２にその例を示すように、マルチメディア送出装置１０が、インターネット２０を介して複数の利用者端末３０、４０、．．．に接続可能であり、また、ＬＡＮ５０を介して複数の利用者端末６０、．．．に接続可能であるようなネットワーク環境である。このようなネットワーク環境において、マルチメディア送出装置１０は、要求されたマルチメディアデータを利用者端末３０、４０、６０等に対して送出する。具体的な手順としては、まず、利用者端末３０が、マルチメディアデータ送出装置１０に対してマルチメディアデータの送信を要求し、これに対してマルチメディア送出装置１０が、ハードディスク内に保持しているマルチメディアデータを検索し、それを利用者端末３０に送出するという手順で行われる。
【００１４】
マルチメディアデータは、単なるテキストデータや静止画データだけではなく、音声、映像といったリアルタイム性を要するデータをも含んでいる。以下の説明において、マルチメディアデータは、静止画、音声、映像の３種類のデータを含むものとする。すでに説明したように、音声、映像といったリアルタイム性を要するデータは、ネットワークの帯域幅が小さい場合、利用者端末３０上で再生する際に問題が起こる可能性がある。音声データや映像データは、一定のビットレートで再生されないと、正しい聞こえ方、見え方をしないからである。
【００１５】
本発明のマルチメディアデータ送出装置１０は、この問題を解決するために、マルチメディアデータの送出の際に利用者端末３０までのインターネット２０上の帯域幅をある程度検知し、それに基づいてマルチメディアデータ内の静止画、音声、映像のデータをデータのある区間内で順序を変えて送信したり、一部だけを送信したりする。順序を変える理由は、マルチメディアデータ内の一部のデータを他のデータに先立って利用者端末３０にダウンロードさせるためである。このようにすることにより、残りのデータは、少ない帯域幅でリアルタイムに送信することが可能となる。この結果、利用者端末３０は、ダウンロードによる待ち時間も少なく、かつ、マルチメディアデータを乱れることなく視聴させることが可能となる。また、マルチメディアデータの一部だけ送信する理由は、マルチメディアデータのビットレートを下げるためである。具体的には、映像データのコマを落とすことである。映像データは、多少コマが落とされても情報として足りる場合が多く、これにより、少ない帯域幅でも利用者端末３０は、待ち時間を最大限に低減させてマルチメディアデータを正しい速さで再生することが可能となる。
【００１６】
図１に示すように、マルチメディアデータ送出装置１０は、ＣＰＵ１１、キーボード１２、ディスプレイ１３、ネットワークインタフェース１４、バス１５、主メモリ１６、及び、ハードディスク１７を備えて構成されている。管理者は、キーボード１２、ディスプレイ１３を使用してマルチメディアデータ送出装置１０を操作する。ネットワークインタフェース１４は、インターネット２０、ＬＡＮ５０からのデータを受信し、あるいは、インターネット２０、ＬＡＮ５０に対してデータを送信する。ＣＰＵ１１は、バス１５を介して主メモリ１６内のプログラムを起動し、主メモリ１６内の各プログラムは、バス１５を介してハードディスク１７内の情報にアクセスする。主メモリ１６内には、送出エンジン１６１、要求バッファ１６２、第１のバッファ１６３、第２のバッファ１６４が構成されている。また、ハードディスク１７内には、マルチメディア属性情報１７１、ネットワーク情報１７２、マルチメディアデータ１７３が格納されている。なお、これらの働きについては後述する。
【００１７】
マルチメディアデータ送出装置１０の機能は、図３に示すようなものである。そして、この機能は、図１により説明した主メモリ１６内に設けられる要求バッファ１６２からの要求に従って、ハードディスク１７内のマルチメディア属性情報１７１とネットワーク情報１７２とから必要な情報を読み出して第１のバッファ１６３に格納し、また、モード種別等に従って、送信するデータの内容と順序とを第２のバッファ１６４に格納し、この第２のバッファ１６４の内容に従って、マルチメディアデータ１７３を読み出して、送信エンジン１６１からネットワークインタフェース１４、インターネット２０またはＬＡＮ５０を介して利用者端末にマルチメディアデータを送信するものである。
【００１８】
以下、図３を参照して、マルチメディア送出装置１０が、少ない帯域幅のネットワークを介して効率よくマルチメディアデータを送出する方法について説明する。
【００１９】
ここで、利用者端末３０でマルチメディアデータを再生する方法として、「リアルタイム」モードと「画質優先」モードとの２種類のモードを与えることとする。「リアルタイム」モードは、マルチメディアデータができるだけ時間通りに再生されることを送出装置に対して要求するモードであり、例えば、マルチメディアデータが全部で３０秒の内容だとすると、ネットワークの帯域幅にかかわらず再生が３０秒で終了するように送出することを要求するモードである。一方、「画質優先」モードは、ネットワークの帯域幅が小さい場合、リアルタイム性を犠牲にし、画質を落とさないことを優先するモードである。なお、このモードは、リアルタイム性を犠牲にするが、ある区間単位では映像、音声が正しく連続的に再生されることを要求するものである。
【００２０】
図３において、ネットワークインタフェース１４は、インターネットからマルチメディアデータの送信要求を受信すると、受信した要求を要求バッファ１６２に渡す。このとき、図７に示すように、区間指定１６２０１、モード種別１６２０２、利用者端末のＩＰアドレスである端末アドレス１６２０３の３つが指定される。区間指定１６２０１は、利用者端末が要求しているデータ区間であり、具体的には、マルチメディアデータの先頭を０秒として何秒後までのデータが欲しいかが指定され、例えば、２５秒目から３０秒までのデータが欲しい場合、その指定がなされる。モード種別１６２０２は、すでに説明した再生モードの種別である。端末アドレス１６２０３は、要求を行った利用者端末のＩＰアドレスである。
【００２１】
要求バッファ１６２内にこれらの内容が指定されて格納されると、次に、マルチメディア属性情報１７１がアクセスされる。ここで、図４を用いてマルチメディア属性情報１７１の構造を説明する。マルチメディアデータは、予め意味のある単位で区間分けされている。例えば、１つの静止画データが表示される時間を１つの区間として区分けされている。これを示したのが図４の１７１０４であり、それぞれの区間の中には、静止画、音声、映像データの属性データが格納されている。具体的には、静止画のバイト数１７１０１、音声データのビットレート１７１０２、映像データのビットレート及びコマ情報１７１０３等である。マルチメディアデータ送出装置１０は、これらの属性情報を用いることにより、送出順序を変えたり送出データを選択したりすることが可能となる。マルチメディア属性情報１７１は、前述したような構造を持つことにより、マルチメディアデータの区間情報と各データの属性情報とを格納することができる。なお、区間の分け方は、前述のように１つの静止画データが表示される時間ではなく、動画である映像データの性質等の状況が大きく変わるポイントによってもよい。
【００２２】
ここで、再度、図３を参照すると、前述した手順により、要求バッファ１６２内の再生区間に該当する部分である１つの区間１７１０４がマルチメディア属性情報１７１から取り出しして、第１のバッファ１６３に格納されたことになる。
【００２３】
一方、ネットワーク情報１７２には、マルチメディアデータを送信する端末のＩＰアドレスとその端末へ接続されるネットワークの帯域幅とが対応付けて格納されている。要求バッファ１６２内に保持されたＩＰアドレスとネットワーク情報１７２とにより、送出先までのネットワークの帯域幅を得ることができ、これが第１のバッファ１６３に格納される。また、要求バッファ１６２に格納されていたモード種別も、第１のバッファ１６３に格納される。前述の結果、第１のバッファ１６３には、指定された区間のマルチメディア属性情報と、利用者端末までのネットワークの帯域幅の情報と、モード種別の情報とが格納されたことになる。次に、これらの情報を用いて、実際に送信されるべきデータの内容とその順序が決められ、その結果が第２のバッファ１６４に格納される。この送信内容に従って、マルチメディアデータ１７３が取り出され、送信エンジン１６１によりネットワークインタフェース１４を介してインターネット２０等のネットワークに送信される。
【００２４】
第２のバッファ１６４に格納される送信内容をどのようにして決定するかは、モード種別によって大きく異なる。モード種別が「リアルタイム」モードの場合、できるだけ実時間で送信することが要求されているので、ネットワークの帯域幅が映像データの全てを実時間で送信することができない大きさの場合、映像データのコマ落としが行われる。そして、コマ落としを行った結果、映像データの送信ビットレートがネットワークの帯域幅を下回る程度までとなるようにする。但し、映像データがＭＰＥＧのようなフレーム（コマと同義）間補償を行う方式の圧縮技術を用いて作られている場合、コマ落としの方法によっては、利用者端末内のデコーダがうまく再生できない場合がある。その場合、第１のバッファ１６３内にあるアクセスポイントの情報を用いて、アクセスポイントのデータを優先的に送信するようにする。
【００２５】
一方、モード種別が「画質優先」モードの場合、映像のコマ落としを行わない。その代わりに、ネットワークの帯域幅を超えないようにマルチメディアデータ内の各データを順番に送出する。例えば、リアルタイム性の必要ない静止画データを先に送出する。そして、残りの映像データと音声データとを同時に送信したときにネットワークの帯域幅を下回るか否かをチェックし、下回る場合、残りを同時に送信し、そうでない場合、映像データあるいは音声データを先に送信し、最後に残りを送信する。
【００２６】
利用者端末は、静止画データについてそのデータが到着次第それを画面に表示する。これにより、利用者端末は、ネットワークの帯域幅不足による遅れを生じさせることなく、時間通りにマルチメディアデータを再生することができる。一方、利用者端末は、映像データや音声データのどちらか片方のデータが到着した場合、そのデータをバッファに一時的に蓄積しておき、残りのデータが到着した時点で同期させながら再生する。これにより、利用者端末は、映像と音声とを同時に再生することができ、ネットワークの帯域幅不足による品質の低下を防止してこられのデータを再生することができる。このアルゴリズムの詳細については、後述する。
【００２７】
前述した説明から判るように、本発明の実施形態によるマルチメディアデータ送出装置１０は、少ない帯域幅のネットワークの場合でも、利用者端末に最大限効率よくマルチメディアデータを送出することが可能である。
【００２８】
次に、図５に示すテーブル例を参照して、マルチメディア属性情報１７１の内容について説明する。マルチメディア属性情報１７１は、マルチメディアデータ内の映像データ、音声データ、静止画データの属性情報が格納されているテーブルである。図５において、１７１５２の列は、マルチメディアデータ内の映像データの各フレームの時刻を示している。図には、幾つかのコマを纏めた間隔を意味区間と定め、これらの意味区間を横線で区切って示している。１７１５１の列が前記した各意味区間の範囲を示している。この意味区間は、この例では、マルチメディアデータの再生によって映像データと同時に表示される静止画データの変わり目を区間の変わり目としている。１７１５６の列には、意味区間内で表示される静止画データのバイト数が格納されている。１７１５３の列には、各意味区間における映像データの平均ビットレートが格納されている。１７１５４の列には、映像データのフレームのうちアクセスポイントとなるフレームが示されている。アクセスポイントとは、１つのフレームのデータだけを利用者端末に送出した場合にも、利用者端末上で正しく表示できるフレームを意味する。ＭＰＥＧ等の動き補償技術を用いて符号化を行った映像データは、任意のフレームを利用者端末に送出しても、そのフレームを再生できるとは限らず、前述のようなアクセスポイントが存在し、前述したように、ＭＰＥＧ等により符号化された映像データの場合、アクセスポイントからのデータを送信する。１７１５５の列には、意味区間内で再生される音声データの平均ビットレートが格納されている。
【００２９】
マルチメディア属性情報１７１は、全てマルチメディアデータ１７３そのものから得ることができる。しかし、マルチメディアデータを送信する前に、マルチメディアデータの属性情報に基づいてデータの選択の処理をリアルタイムに行う必要がある。マルチメディア属性情報を前もって作成しておくとにより、送信しながらマルチメディアデータの選択の処理を行うことが容易となる。
【００３０】
次に、図６に示すテーブルの例を参照して、ネットワーク情報１７２の内容について説明する。ネットワーク情報１７２は、マルチメディア送出装置１０がデータを送出する相手先である利用者端末３０へのネットワークの帯域幅の情報を格納している。図６において、１７２０１の列には、送出先の利用者端末のＩＰアドレスが格納されている。この例では、１つ１つの数字が複数のＩＰアドレスをまとめて表現している。例えば、図示の「１２３．４５６．７８９．０００」は、「１２３．４５６．７８９」で始まるアドレスを全て表している。１７２０２の列は、それぞれのＩＰアドレス群に対応したネットワークの帯域幅を示している。このテーブルを用いることにより、送出先の利用者端末を接続するネットワークの帯域幅を得ることが可能となる。
【００３１】
次に、図８に示すテーブルの例を参照して、第１のバッファ１６３の内容について説明する。図８において、１６３０１〜１６３０６の各列は、マルチメディア属性情報１７１内のある１つの意味区間のデータを取り出した内容である。また、１６３０７の列には、要求バッファ１６２に格納されていた再生モード種別が格納される。第１のバッファ１６３には、利用者端末が要求した意味区間単位のマルチメディアデータに関わる情報がシナリオ情報として一時的に格納される。そして、要求されるマルチメディアデータを構成する複数の意味区間のデータが意味区間毎に図８に示すようなテーブルとして第１のバッファに格納される。
【００３２】
次に、図９（ａ）を参照して、利用者端末が「リアルタイム」モードを指定した場合における第２バッファ１６４の内容の例について説明する。図９（ａ）において、１６４０１〜１６４０６の各列の２行目以下の各行１６４０６〜１６４１０には、映像データの各フレーム毎の情報が格納されている。列１６４０１には、映像データのフレームが再生される時刻が格納され、列１６４０４には、映像データの各フレームについて、送信するものについて「１」、送信しないものについて「０」が格納されている。これは、ネットワークの帯域幅の条件に照らし合わせた結果、一部のフレームのみが送信され、残りは送信しないと判断した結果である。この映像データの場合、図８に示しているように、アクセスポイントが一部のフレームに限られているため、送信するべきフレームはアクセスポイントのフレームとなっている。列１６４０３は、各時刻における音声データのうち、送信されるものについて「１」が指定されている。図示例の場合、全てのデータを送ることとなる。列１６４０２は、静止画を送信する時刻に関する情報である。静止画データは、図示している意味区間に１つのデータがあり、図示例の場合、この区間が始まってすぐに送信を行ってしまうことを意味している。
【００３３】
次に、図９（ｂ）を参照して、利用者端末が「画質優先」モードを指定した場合における第２のバッファ１６４の内容の例について説明する。「リアルタイム」モードの場合と異なっているのは、ネットワーク帯域幅が小さい場合に各データの送信順序を変えることである。図９（ｂ）において、最も上の第１行１６４５５に「１」が格納されているのは、予めデータを利用者端末に送信をすませておくことを意味する。図示例の場合、列１６４５２の静止画と１６４５４の映像データとについて、この区間に送信するべき内容を、予め送信を非リアルタイムに済ませておくことを意味する。その後、列１６４５３に示すように、音声データのみが時間通りに送信される。
【００３４】
送信エンジン１６１は、前述したような第２のバッファ１６４の内容に従って送信を行うことにより、限られたネットワークの帯域幅の中で有効なマルチメディアデータの送信を行うことが可能となる。
【００３５】
図１０は第１のバッファ１６３の内容により第２のバッファ１６４の内容を決定するアルゴリズムを説明するフローチャート（その１）であり、以下、これについて説明する。ここで説明するフローは、第１のバッファ１６３内に「リアルタイム」モードが指定されている場合の例である。
【００３６】
（１）最初に、ネットワークの帯域幅（図８、１６３０１）の値と、映像、音声、静止画の各データの合計の平均のビットレートとを比較して、通常通りこれらのデータを送信してもネットワークの帯域幅が充分か否かをチェックし、通常通りに送信することが可能な場合、各データを通常通りに送信する（ステップ５１、５６）。
【００３７】
（２）ステップ５１のチェックで、通常通りに送信することができない場合、映像データのコマを落とした場合にネットワークの帯域幅が充分となるか否かを調べ、フレームを落として充分となる場合、映像データから必要なだけのフレームを落として送信を行う。この場合、送信する映像データは、アクセスポイント（図８、１６３０４）の映像データとする（ステップ５２、５７）。
【００３８】
（３）ステップ５２のチェックで、映像データのフレームを落としてもなお、マルチメディアデータのスループットがネットワークの帯域幅を超える場合、映像データとして最初のコマのデータのみを送信してネットワークの帯域幅を超えないか否かを調べ、超えない場合、映像データの最初のフレームのみの送信を行う（ステップ５３、５８）。
【００３９】
（４）ステップ５３のチェックで、映像データの最初のフレームのみを送信してもネットワークの帯域幅を超える場合、リアルタイムに送信することが不可能であるので、この処理を失敗とする（ステップ５５）。
【００４０】
図１１は第１のバッファ１６３の内容により第２のバッファ１６４の内容を決定するアルゴリズムを説明するフローチャート（その２）であり、以下、これについて説明する。ここで説明するフローは、第１のバッファ１６３内に「画質優先」モードが指定されている場合の例である。
【００４１】
（１）最初に、ネットワークの帯域幅（図８、１６３０１）の値と、映像、音声、静止画の各データの合計の平均のビットレートとを比較して、通常通りこれらのデータを送信してもネットワークの帯域幅が充分か否かをチェックし、通常通りに送信することが可能な場合、各データを通常通りに送信する（ステップ６１、６６）。
【００４２】
（２）ステップ６１のチェックで、通常通りに送信することができない場合、静止画データを除いた他のデータを送るとした場合にネットワークの帯域幅が充分となるか否かを調べ、充分となる場合、静止画データを先に送信して、その後に他のデータを通常通りに送信する（ステップ６２、６７）。
【００４３】
（３）ステップ６２のチェックで、静止画データを除いてもネットワークの帯域幅が充分でなかった場合は、静止画データと映像データをと除いた他のデータを送るとした場合にネットワークの帯域幅が充分となるか否かを調べ、充分となる場合、静止画データと映像データとを先に送信してしまい、音声データのみを通常通りに送信する（ステップ６３、６８）。
【００４４】
（４）ステップ６３のチェックで、静止画データと映像データとを先に送信してもネットワークの帯域幅が充分ならない場合、全てのデータを非リアルタイム送信として送信する。この結果、全てのデータは、利用者端末上で一時的にキャッシュされて再生される（ステップ６５）。
【００４５】
前述した図１０に説明したフローにおいて、第１のバッファ１６３の内容が図８に示す通りである場合、このフローによるアルゴリズムを適用して第２のバッファ１６４がどのようになるかについて説明する。
【００４６】
最初に、ステップ５１のチェックで、各データを通常通りに送信すると仮定した平均ビットレートを調べる。図８に示す例の場合、映像データの５フレーム時間に渡る図８に示す区間での２０ＫＢの大きさを持つ静止画の平均ビットレートは、２０×８÷５＝３２ｋｂｐｓとなり、各データを合算した図示区間の平均ビットレートは、２５６＋６４＋３２＝３５２ｋｂｐｓとなる。この値は、ネットワークの帯域幅１６３０１に示される２００ｋｂｐｓを超えている。よって、次に、ステップ５２のチェックで、映像データのフレームを落としてみる。映像データは、各フレーム当たりのバイト数が同じであると仮定すると、フレームを２枚送ると帯域幅を超えないことが判る。すなわち、この場合、映像データの平均ビットレートは、２５６÷５×２＝１０２．４ｋｂｐｓとなり、各データを合算した平均ビットレートは、１０２．４＋６４＋３２＝１９８．４ｋｂｐｓとなる。この値は、ネットワークの帯域幅１６３０１に示される２００ｋｂｐｓ以内に収まるものであり、映像アクセスポイントを１６３０４から得て、映像データに関してはアクセスポイントとして指定されたフレームのみを送信する。このようにして第２のバッファの内容が決定する。
【００４７】
次に、前述した図１１に説明したフローにおいて、第１のバッファ１６３の内容が、図８におけるモード種別が「画質優先」モードとなっている場合について、このフローによるアルゴリズムを適用して第２のバッファ１６４がどのようになるかについて説明する。
【００４８】
最初に、ステップ６１のチェックで、各データを通常通りに送信すると仮定した平均ビットレートを調べる。この場合、前述した場合と同一であり、図示区間の平均ビットレートは３５２ｋｂｐｓとなり、ネットワークの帯域幅１６３０１の２００ｋｂｐｓを超えているので、ステップ６２で静止画データを除いたと仮定して、平均ビットレートを求める。この場合、２５６＋６４＝３２０ｋｂｐｓとなり、これでもネットワークの帯域幅を超えている。次に、ステップ６３のチェックで、静止画データと映像データとを除いたと仮定して平均ビットレートを求めると、音声データのみの６４ｋｂｐｓとなる。この値は、ネットワークの帯域幅を超えていない。従って、静止画データ及び映像データを先に送信して、音声データを時間通りに送信するという結果を得ることができる。
【００４９】
前述で説明したように、図１０、図１１に示したフローによるアルゴリズムを用いることにより、第１のバッファ１６３に格納された意味区間単位の送信要求に対して、ネットワークの帯域幅内で効率よくマルチメディアデータを送信する方法を第２のバッファ１６４に格納することが可能となる。
【００５０】
前述した本発明の実施形態は、本発明を、あるネットワーク環境におけるマルチメディア送出装置に適用したものとして説明したが、本発明は、ネットワーク環境に適用される場合に限られるものではなく、例えば、同一のコンピュータ内で動作するマルチメディアデータ表示アプリケーションに対して、マルチメディアデータをハードディスクなどから読み出し提供する装置にも適用することができる。この場合、前述で説明した本発明の実施形態における利用者端末をマルチメディアデータ表示アプリケーションとし、それとの間に位置するネットワークをコンピュータ内の伝送経路、例えば、バス装置等とすればよい。
【００５１】
また、前述した本発明実施形態におけるマルチメディア送出装置内の処理は、プログラムにより実行させることができ、そのプログラムは、ＦＤ、ＣＤＲＯＭ、ＤＶＤＲＯＭ、ＭＯ等の記録媒体に格納して提供することができる。
【００５２】
前述したように本発明の実施形態によれば、マルチメディアデータを構成する映像データの一部のみ送信したり、マルチメディアデータ内の各データの送信順序を変えることが可能となり、マルチメディア送出装置及び視聴者端末の間のネットワークの帯域幅が少ない場合でも、視聴者端末上で再生表示が乱れることなく、また待ち時間も少なく、高品質のマルチメディアデータの表示を行わせることができる。
【００５３】
【発明の効果】
以上説明したように本発明によれば、ネットワーク環境の帯域幅に応じて、送信するマルチメディアデータの送信ビットレートを動的に調整することができ、視聴者端末上で高品質のマルチメディアデータの表示を行わせることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるマルチメディアデータ送出装置のハードウェア構成を示すブロック図である。
【図２】本発明によるマルチメディアデータ送出装置が適用されるネットワーク構成を示すブロック図である。
【図３】本発明の一実施形態によるマルチメディアデータ送出装置の機能構成を示すブロック図である。
【図４】マルチメディア属性情報の構造を説明する図である。
【図５】マルチメディア属性情報を格納したテーブルの内容を示す図である。
【図６】ネットワーク情報を格納したテーブルの内容を示す図である。
【図７】要求バッファに格納される情報内容を説明する図である。
【図８】第１のバッファにテーブルとして格納される情報内容を説明する図である。
【図９】第２のバッファにテーブルとして格納される情報内容を説明する図である。
【図１０】第１のバッファの内容により第２のバッファの内容を決定するアルゴリズムを説明するフローチャート（その１）である。
【図１１】第１のバッファの内容により第２のバッファの内容を決定するアルゴリズムを説明するフローチャート（その２）である。
【符号の説明】
１０ マルチメディアデータ送出装置
１１ ＣＰＵ
１２ キーボード
１３ ディスプレイ
１４ ネットワークインタフェース
１５ バス
１６ 主メモリ
１６１ 送出エンジン
１６２ 要求バッファ
１６３ 第１のバッファ
１６４ 第２のバッファ
１７ ハードディスク
１７１ マルチメディア属性情報
１７２ ネットワーク情報
１７３ マルチメディアデータ
２０ インターネット
３０、４０、６０ 利用者端末
５０ ＬＡＮ
Claims (3)
- マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、
前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、
前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、
前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、
前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、
前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記シナリオ情報に基づき再生されるマルチメディアデータを構成するデータのうち、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるビットレートで送信可能な第１のデータ以外の他のデータである第２のデータを送信し、該第２のデータの送信が完了するまで、前記第１のデータを保持しておき、前記第２のデータの送信が終了した後、保持していた前記第１のデータをリアルタイムに送信することを特徴とするマルチメディアデータ送出装置。 - マルチメディアデータを蓄積する手段と、表示アプリケーションから受信した前記マルチメディアデータの呼び出し要求に応じて、前記マルチメディアデータを前記表示アプリケーションヘ送信する手段とを有するマルチメディアデータ送出装置において、
前記マルチメディアデータを構成する映像、音声、静止画の各データを前記表示アプリケーション上で再生するために当該マルチメディアデータの再生の開始時点を基準とした、各データを再生する時刻を記述したシナリオ情報を蓄積する手段と、
前記表示アプリケーションとの間に位置する伝送経路の帯域幅の値を保持する手段と、
前記マルチメディアデータを構成する映像データのビットレート、音声データのビットレート及び静止画データのバイト数を予め抽出して保持する手投と、
前記静止画データのバイト数と、前記シナリオ情報において記述される、当該静止画データの送信に要する時間から当該静止画データを送信する場合のビットレートを算出する手段とを備え、
前記シナリオ情報に記述された時刻に、当該各時刻に対応するデータを送信する場合に、マルチメディアデータを構成する映像データ、音声データ及び静止画データのうち、同時に送信される映像データのビットレート、音声データのビットレート、及び、前記算出した静止画データを送信する場合のビットレートの合計が、前記伝送経路の帯域幅の値を超える場合、前記映像データのフレームを落とし、前記シナリオ情報で定義されている前記伝送経路の帯域幅に収まるようにして前記各データを送信することを特徴とするマルチメディアデータ送出装置。 - 前記表示アプリケーションが利用者端末に備えられる表示アプリケーションであり、前記伝送経路がネットワークであることを特徴とする請求項１または２記載のマルチメディアデータ送出装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000263586A JP3860957B2 (ja) | 2000-08-31 | 2000-08-31 | マルチメディアデータの送出装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000263586A JP3860957B2 (ja) | 2000-08-31 | 2000-08-31 | マルチメディアデータの送出装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002077857A JP2002077857A (ja) | 2002-03-15 |
| JP3860957B2 true JP3860957B2 (ja) | 2006-12-20 |
Family
ID=18751113
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000263586A Expired - Fee Related JP3860957B2 (ja) | 2000-08-31 | 2000-08-31 | マルチメディアデータの送出装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3860957B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4596766B2 (ja) * | 2003-11-13 | 2010-12-15 | 日本電信電話株式会社 | メディア通信制御方法、メディア通信制御装置、および、メディア提供システム、ならびに、メディア通信制御プログラム、および、その記憶媒体 |
| KR100488595B1 (ko) | 2004-07-29 | 2005-05-11 | 엔에이치엔(주) | 동영상 공동 관람 서비스 제공 방법 및 시스템 |
| JP2006333254A (ja) * | 2005-05-27 | 2006-12-07 | Fujifilm Holdings Corp | 動画像リアルタイム通信端末、動画像リアルタイム通信端末の制御方法及び動画像リアルタイム通信端末の制御プログラム |
| JP4914127B2 (ja) * | 2005-07-11 | 2012-04-11 | キヤノン株式会社 | ネットワークカメラ装置およびネットワークカメラ装置の映像フレームの送信方法 |
| JP4527627B2 (ja) * | 2005-08-04 | 2010-08-18 | 日本電信電話株式会社 | コンテンツの配信装置，コンテンツ配信ネットワークおよびコンテンツ配信方法 |
| US7877777B2 (en) | 2006-06-23 | 2011-01-25 | Canon Kabushiki Kaisha | Network camera apparatus and distributing method of video frames |
| US10142410B2 (en) | 2016-04-29 | 2018-11-27 | Raytheon Company | Multi-mode remote collaboration |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3086075B2 (ja) * | 1992-07-10 | 2000-09-11 | 富士通株式会社 | Ａｔｍ交換機における帯域予約方式 |
| JPH06243058A (ja) * | 1993-02-15 | 1994-09-02 | N T T Data Tsushin Kk | メディア同期再生装置 |
| JPH06348580A (ja) * | 1993-06-08 | 1994-12-22 | Hitachi Micom Syst:Kk | マルチメディア転送装置 |
| JPH0766919A (ja) * | 1993-08-27 | 1995-03-10 | Canon Inc | 通信装置 |
| JPH0779435A (ja) * | 1993-09-06 | 1995-03-20 | Nippon Telegr & Teleph Corp <Ntt> | 映像符号化装置 |
| JPH09128367A (ja) * | 1995-11-02 | 1997-05-16 | Matsushita Electric Ind Co Ltd | 情報提供装置 |
| JP3486303B2 (ja) * | 1996-07-24 | 2004-01-13 | 日本電信電話株式会社 | マルチメディア情報転送方法及びその装置 |
| JP3478690B2 (ja) * | 1996-12-02 | 2003-12-15 | 株式会社日立製作所 | 情報伝送方法及び情報記録方法と該方法を実施する装置 |
| JPH10276407A (ja) * | 1997-03-31 | 1998-10-13 | Nippon Telegr & Teleph Corp <Ntt> | ビデオ情報提供管理方法およびシステム |
| JPH10313363A (ja) * | 1997-05-13 | 1998-11-24 | Casio Comput Co Ltd | 情報送信装置及び情報送信方法 |
| JP3606729B2 (ja) * | 1997-12-10 | 2005-01-05 | 松下電器産業株式会社 | リッチテキスト素材の表示方法及び映像情報提供システム |
| JPH11215193A (ja) * | 1998-01-28 | 1999-08-06 | Matsushita Electric Ind Co Ltd | マルチメディア再生システムにおけるデータ転送装置 |
| JP4244394B2 (ja) * | 1998-02-17 | 2009-03-25 | 富士ゼロックス株式会社 | 多地点会議システム |
| JPH11261988A (ja) * | 1998-03-11 | 1999-09-24 | Nippon Telegr & Teleph Corp <Ntt> | 情報配信方法及びシステム及びサーバ装置及びクライアント装置 |
| JPH11261978A (ja) * | 1998-03-11 | 1999-09-24 | Sony Corp | 情報処理装置および方法、並びに提供媒体 |
| JPH11313048A (ja) * | 1998-04-24 | 1999-11-09 | Kokusai Electric Co Ltd | マルチメディア通信方法及び通信装置 |
| JP3563278B2 (ja) * | 1998-06-19 | 2004-09-08 | 日本電信電話株式会社 | 優先経路制御方法及びルータ装置 |
| JP2000013777A (ja) * | 1998-06-26 | 2000-01-14 | Matsushita Electric Ind Co Ltd | 映像再生装置及び映像蓄積装置 |
| JP2995177B1 (ja) * | 1998-07-10 | 1999-12-27 | 株式会社ディジタル・ビジョン・ラボラトリーズ | ストリーム配信システム |
| JP2000101647A (ja) * | 1998-09-25 | 2000-04-07 | Matsushita Electric Ind Co Ltd | データ送信方法、データ送信装置、及びデータ送信プログラムを記録した記録媒体 |
| JP2000207234A (ja) * | 1999-01-08 | 2000-07-28 | Mitsubishi Electric Corp | 通信システム |
| JP3709730B2 (ja) * | 1999-02-03 | 2005-10-26 | 三菱電機株式会社 | データ中継装置及びデータ中継方法 |
-
2000
- 2000-08-31 JP JP2000263586A patent/JP3860957B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002077857A (ja) | 2002-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11470138B2 (en) | Apparatus, system, and method for multi-bitrate content streaming | |
| JP4818562B2 (ja) | 漸進的により高品質のバージョンのオーディオおよび／またはビデオプログラムを得るための方法およびコンピュータネットワーク | |
| JP5288710B2 (ja) | マルチメディアデータを記録した情報保存媒体、その再生方法及び再生装置 | |
| EP2649792B1 (en) | Pre-buffering audio/video stream pairs | |
| JP3874714B2 (ja) | キャッシング技法を用いたｍｐｅｇ−４システム端末の制御方法 | |
| US7594025B2 (en) | Startup methods and apparatuses for use in streaming content | |
| JP2007529121A (ja) | ストリーミングメディアの疎（ｓｐａｒｓｅ）キャッシング | |
| KR19990087916A (ko) | 인터넷콘볼루션오디오/비디오서버 | |
| EP1743249A2 (en) | Apparatus, system, and method for adaptive-rate shifting of streaming content | |
| JP2001204001A (ja) | 動画像配信システム，再生端末装置，及び配信装置 | |
| CN113141522B (zh) | 资源传输方法、装置、计算机设备及存储介质 | |
| US20020157102A1 (en) | Moving picture streaming method in VOD system | |
| US9665646B1 (en) | Method and system for providing bit rate adaptaion to video files having metadata | |
| JP3860957B2 (ja) | マルチメディアデータの送出装置 | |
| KR20070024747A (ko) | 네트워크 스위칭을 이용한 스트리밍 서비스 장치 및 방법 | |
| KR100931344B1 (ko) | Ｖｏｄ 스트리밍 서비스를 제공하는 방법과 그를 위한시스템, 서버 및 사용자 단말기 | |
| Kinoshita et al. | Low Latency Live Streaming System with Congestion Control | |
| JP3920716B2 (ja) | ストリーミングサービスの配信レート変更方法及びストリーム配信サーバ並びにストリーム配信プログラム及びその情報記録媒体 | |
| JP3670581B2 (ja) | 映像音声配信装置及び映像音声ファイル解析方法 | |
| JP2002158657A (ja) | ストリーム配信方法及びストリーム配信システム | |
| KR20090000281A (ko) | Ｃｅ 기기의 데이터 수신 장치 및 방법, 데이터 재생 방법및 ｃｅ 기기 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050630 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051129 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060127 |
|
| 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: 20060919 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060925 |
|
| 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: 20090929 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100929 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100929 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110929 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120929 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120929 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130929 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |