JP3320595B2 - 動画再生制御方法及び動画サーバ - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、動画サーバ及び動
画再生制御方法に係り、特にネットワークを介して複数
の利用者から動画再生要求を受ける動画サーバ及び動画
再生制御方法に関する。

【０００２】

【従来の技術】従来よりネットワークを介して複数のユ
ーザに動画再生サービスを行なうビデオサーバ等のシス
テムが提案もしくは実現されている。この場合に動画を
途切れずに再生することは重要なことである。このため
に、ワーストケースデザインをし、最悪の場合でも動画
データの転送が間に合わないことがないように、余裕を
もったスケジューリングや伝送を行なう。これは安全で
はあるが、システムの性能限界よりも大きく劣った動画
データ配信能力に留まる。例えば、動画データの１スト
リーム当たりの伝送速度の最大値が１０Ｍｂｐｓでネッ
トワークの伝送容量が１００Ｍｂｐｓであった場合に
は、安全に供給できるストリーム数は（ネットワークの
伝送容量／１ストリーム当たりの最大伝送速度）＝１０
となる。しかし、１ストリーム当たりの最大伝送量が１
０Ｍｂｐｓと多い場合であっても、１ストリーム当たり
の平均伝送量は４Ｍｂｐｓと低い場合が多い。この場
合、期待値としては１００Ｍｂｐｓ／４Ｍｂｐｓ＝２５
ストリームで伝送できる。

【０００３】また、ユーザが動画データの再生を要求し
てから最初の画面が出るまでにある程度時間がかかるこ
とがある。このような場合に対し、特開平５−２０７２
４７号公報に開示された静止画像情報再生装置では、最
初に限り静止画を出してユーザを待たせるようにする技
術が開示されている。しかし、上記公報では動画再生途
中については述べられていない。

【０００４】また、同じタイトルに対して時間上でずれ
て複数の再生要求があった場合に、それらの要求を同期
させることにより、より少いストリーム数でサービスが
可能となる。例えば、同じ映画の再生を二人の人が１５
秒のずれで要求した場合に、二本のビデオストリームを
それぞれに用いるのではなく、先に要求した人の再生を
１５秒ずらして二人の要求に対して一本のストリームを
用いると資源の節約になる。従来技術としては、先に再
生要求した方に対して動画の再生を少し遅くして同期を
取るという方法が提案されている。しかし、僅かに再生
を遅くすることは技術的に困難である。すなわち、遅く
する度合を小さくするとユーザに対して違和感を与える
ことが少い代わりに再生速度を遅くする期間が長くな
る。また逆に再生速度を遅くする度合を高めると、再生
速度を遅くする期間を短縮できる代わりに、ユーザに与
える違和感が大きくなる。

【０００５】さらに、動画サーバに障害が生じた場合
に、ユーザの画面で配信中のコンテンツの内容とは無関
係に動画の再生が中断し、ユーザに不快感を与えるとい
う問題がある。

【０００６】

【発明が解決しようとする課題】動画サーバーにＭＰＥ
Ｇ１やＭＰＥＧ２といった転送（情報）レートの異なる
情報が保持され、動画サーバから転送する必要がでてく
る。例えば、一つのタイトルであっても、動画の様子に
合わせて異なる転送（情報）レートで保持されることも
将来は考えられる。

【０００７】この場合に、動画転送の連続性を保証する
ためには、最大転送レート時でも転送上にネックがない
ようにする必要がある。例えば、一部だけＭＰＥＧ２
（４Ｍｂｐｓ）でエンコードされているが、その他の部
分がＭＰＥＧ１（１．５Ｍｂｐｓ）で保持されているタ
イトルが複数あるとする。もし、１０Ｍｂｐｓの転送路
でこれらを転送しようとすると、１０Ｍｂｐｓを最大転
送レートである４Ｍｂｐｓで割った２本のストリームし
か流すことができない。これは確実に連続性を保証する
という厳しい条件からきた結果である。

【０００８】しかし、期待値としては、もっと多くのス
トリームを流す能力があることは明かである。そこで、
転送路上の混雑のために転送できなくなった場合に何ら
かの処置をするようにして、安全確実に送れるストリー
ムよりも多くのストリームを供給することが要求され
る。

【０００９】また、従来は時刻のずれた動画再生要求に
対しては別々のストリームを割り当てることが一般的に
行なわれている。研究室レベルでは先行する動画の再生
を遅くして二つの動画を同期させストリーム数を減少さ
せるという提案はある。しかし、現実的に容易な方法で
ストリーム数を減らす方法は提案されていない。

【００１０】さらに、動画サーバの障害により動画の配
信ができなくなった場合にも、動画の意味とは無関係な
切れ目で動画の配信が中断するのではなく、動画の意味
的な切れ目で動画の表示を中断することも望まれる。こ
のようにすれば、視聴者に比較的不快感なく、動画の配
信を一時中止することができる。

【００１１】以上のように、動画データを効率の良いス
ケジューリングによって取り出し、なるべく少いストリ
ームで多くのユーザに動画データを違和感なく提供する
ことが望まれる。

【００１２】本発明は、上記事情を考慮してなされたも
のであり、ネットワークを介して複数のユーザに動画再
生サービスを行なうシステムにおいて、過負荷時、障害
時、同一タイトルの複数ユーザ読みだし時に、ユーザに
違和感を与えることを少くして、伝送効率を最大限に引
き上げることのできる動画再生制御方法及び動画サーバ
を提供することを目的とする。

【００１３】

【課題を解決するための手段】本発明（請求項１）は、
複数の動画情報が記憶されている記憶装置から、端末よ
り要求された動画情報を読みだし該端末に配信して再生
させるための動画サーバの動画再生制御方法において、
前記動画サーバ内に、動画の意味的な切れ目を持つ位置
の情報を該動画と対応付けて記憶しておくとともに、動
画の配信を一時中断した場合に前記端末に送って表示せ
るべき別画像を予め用意しておき、前記動画サーバは、
動画再生をとぎれさせると判断された場合には、前記意
味的な切れ目を持つ位置まで動画を配信し、その位置に
おいて動画の配信を一時中断し、動画の配信を一時中断
させた直後から、予め用意しておいた前記別画像を前記
端末に送って表示させることを特徴とする。また、本発
明（請求項２）は、複数の動画情報が記憶されている記
憶装置から、端末より要求された動画情報を読みだして
端末に配信して再生させるための動画サーバの動画再生
制御方法において、前記動画サーバ内には、動画の意味
的な切れ目を持つ位置の情報を該動画と対応付けて記憶
しておき、前記動画サーバは、動画再生をとぎれさせる
と判断された場合には、前記意味的な切れ目を持つ位置
まで動画を配信し、その位置において動画の配信を一時
中断し、動画の配信を一時中断させた直後に、前記端末
へ、該端末内に動画配信の中断時のために予め用意され
ている別画像を表示すべき旨の指示を送ることを特徴と
する。好ましくは、動画情報が保持されている記憶装置
からのデータ読みだしが集中し近い将来にスケジューリ
ングができなくなることが予想された場合、ネットワー
クや回線のトラフィックを監視しトラフィック量が一定
値を越えた場合、もしくは動画サーバ内で瞬時に回復で
きないと予測される障害の発生が検出された場合に、当
該動画読みだし要求に対して、または複数の端末から同
一の動画情報に対する読みだし要求があり且つ要求のあ
った時刻のずれが小さい場合に先行する動画読みだし要
求に対して、次の意味的な切れ目を持つ位置までで動画
の配信を中断し、端末においては次の意味的な切れ目の
位置で再生を中断すると判断するようにしてもよい。好
ましくは、前記読みだし要求に応じて動画を配信すると
端末での動画再生が中断される可能性がある場合には、
使用料金を割り引く、もしくは動画を一時中断した回数
や時間に応じて使用料金を割り引くようにしてもよい。
好ましくは、動画を端末に配信するのに用いるネットワ
ークに障害が生じたかもしくはネットワーク容量を超え
たことにより情報が伝送できない場合には、予め取り決
められた別の伝送路を用いて動画が表示されないことに
ついての情報を該端末に提供するようにしてもよい。ま
た、本発明（請求項６）に係る動画サーバは、複数の動
画情報を記憶するための第１の記憶手段と、前記動画の
意味的な切れ目を持つ位置の情報を前記動画と対応付け
て記憶するための第２の記憶手段と、前記動画の配信を
一時中断した場合に端末に送って表示せるべき別画像を
記憶するための第３の記憶手段と、端末から動画情報の
読みだし要求を受けた場合に、該端末より要求された動
画情報を前記第１の記憶手段から読みだして該端末に配
信するための手段と、前記動画情報の配信中に動画再生
をとぎれさせるか否か判断するための手段と、この手段
により動画再生をとぎれさせると判断された場合に、前
記意味的な切れ目を持つ位置まで動画を配信し、その位
置において動画の配信を一時中断し、動画の配信を一時
中断させた直後から、前記第３の記憶手段に記憶されて
いる前記別画像を前記端末に送って表示させるための手
段とを備えたことを特徴とする。また、本発明（請求項
７）に係る動画サーバは、複数の動画情報を記憶するた
めの第１の記憶手段と、前記動画の意味的な切れ目を持
つ位置の情報を前記動画と対応付けて記憶するための第
２の記憶手段と、端末から動画情報の読みだし要求を受
けた場合に、該端末より要求された動画情報を前記第１
の記憶手段から読みだして該端末に配信するための手段
と、前記動画情報の配信中に動画再生をとぎれさせるか
否か判断するための手段と、この手段により動画再生を
とぎれさせると判断された場合に、前記意味的な切れ目
を持つ位置まで動画を配信し、その位置において動画の
配信を一時中断し、動画の配信を一時中断させた直後
に、前記端末へ、該端末内に動画配信の中断時のために
予め用意されている別画像を表示すべき旨の指示を送る
ための手段とを備えたことを特徴とする。好ましくは、
動画情報が保持されている記憶装置からのデータ読みだ
しが集中し近い将来にスケジューリングができなくなる
ことが予想された場合、ネットワークや回線のトラフィ
ックを監視しトラフィック量が一定値を越えた場合、も
しくは動画サーバ内で瞬時に回復できないと予測される
障害の発生が検出された場合に、当該動画読みだし要求
に対して、または複数の端末から同一の動画情報に対す
る読みだし要求があり且つ要求のあった時刻のずれが小
さい場合に先行する動画読みだし要求に対して、次の意
味的な切れ目を持つ位置までで動画の配信を中断するよ
うにしてもよい。また、本発明は、意味的な切れ目の情
報の付与された動画データを格納する記憶装置と、別情
報を保持する記憶装置と、ネットワークや回線のトラフ
ィックを監視し、かつ前記動画データへのアクセスをス
ケジューリングし、かつ複数の端末から同一の動画デー
タを読みだしていることを認知しそのずれ時間を管理
し、かつ動画情報を取り出して伝送し要求に応じて意味
の切れ目で再生を中断し、かつデータの入力先や出力先
を切替え制御し、かつ端末側に端末内の記憶装置に格納
されている情報を表示することを指示する制御部と、動
画情報を伝送できるネットワークや回線を通して複数の
端末と、動画を表示する端末内の装置と、端末内の記憶
装置と、別情報が挿入された回数と時間とを端末ごとに
集計する装置とからなる。

【００１４】

【００１５】

【００１６】

【００１７】

【００１８】

【００１９】（作用） 本発明（請求項１，２，６，７）では、配信されるべき
動画データには意味的切れ目のデータが付与されてお
り、端末側で動画の連続再生が困難であると動画サーバ
（の制御部）が判断した場合に、次の意味の切れ目で動
画の配信を中断する。これにより、ユーザにとって、動
画の表示が中断されても意味的な切れ目までは見ること
ができる。また、本発明では、動画の配信が中断した後
に、それまでに配信しようとしていた動画に代わって別
情報をユーザに表示する。代替情報としては、動画サー
バ内の動画が格納されている記憶装置とは別の記憶装置
からのデータを代わりに伝送してユーザに表示したり
（請求項１，６）、端末内の記憶装置に格納されたデー
タを表示する（請求項２，７）。これにより、本来ユー
ザが要求した動画の表示サービスが中断しても、ユーザ
に別情報を提供することにより、ユーザを飽きさせずに
待たせることができる。本発明（請求項３）では、請求
項１，２の発明での動画配信の中断を判断する機能を提
供する。すなわち、 （ａ）動画データが保持されている記憶装置からのデー
タの読みだしが集中し近い将来にスケジューリングがで
きなくなることが予想された時、 （ｂ）ネットワークや回線のトラフィックを監視しトラ
フィック量が一定値を超えた時、 （ｃ）動画サーバ内で瞬時に回復できないような障害が
生じた場合を検出した場合に、 （ｄ）複数の端末から同一の動画データへの読みだし要
求があり、かつ両者の時刻のずれが小さい場合には先行
する動画読みだし要求に対して、動画の配信を中断する
判断をする。これにより、動画の配信を中断すべき場合
が明らかになる。本発明（請求項４）では、端末が直接
要求した動画情報ではなく別情報が表示された場合に
は、その回数と時間とを端末ごとに記録しておき、その
結果をサービス料金に反映させる。これにより、サービ
ス低下に対して埋め合わせをすることで、より合理的な
サービスの提供を行なうことができる。本発明（請求項
５）では、動画サーバ内の障害ではなく、動画を配信す
るネットワークに障害が生じたり、ネットワークが容量
を超過し、ネットワークの容量が超過したという情報さ
えも流せなくなった場合には、電話線や電波（地上波、
衛星波など）を用いて動画が端末に表示されない状態説
明、理由、修復にかかる時間などの情報を端末に表示す
る。この場合には、単にテキスト形式で伝送されたもの
を表示してもよいし、符号化されて送られて来た情報が
指示する端末内部に格納されたデータ（動画、静止画、
音声、テキストなど）を表示しても良い。このように動
画が表示されなくなったときに直ちに説明を行うことに
より視聴者に安心感を与える。請求項１，３あるいは請
求項２，３の発明の構成をすべて備えた場合、以下のよ
うな作用効果を得ることができる。 （ａ）ネットワークのトラフィックがあらかじめ決めら
れた値を超え、動画の配信が不可能となる可能性が高い
と予測された場合に、動画のサービスを意味的な切れ目
で動画サーバでの送信および端末での表示を中断し、ネ
ットワークのトラフィックが下るまで、端末にあらかじ
め保持されたデータ（動画、静止画、テキスト）を用い
てユーザを飽きさせずに待たせる。 （ｂ）動画データが保持されている記憶装置からのデー
タの読みだしが集中し近い将来にスケジューリングがで
きなくなることが予想された時に、動画のサービスを意
味的な切れ目で動画サーバでの送信および端末での表示
を中断し、記憶装置への読みだしの集中が緩和されるま
で、動画サーバ内のアクセス集中を起こしていない別の
記憶装置に格納されたデータを代わりに配信して端末に
表示したり、端末にあらかじめ保持されたデータ（動
画、静止画、テキスト）を用いてユーザを待たせる。 （ｃ）動画サーバ内で瞬時に回復できないような障害
（再試行では回復できず、復旧に時間を要するような障
害）が生じた場合を検出した場合に、障害が生じていな
い部位にあるデータおよび通進路を用いて、ユーザに情
報（別の動画、静止画、音声、テキスト）を提供し、ユ
ーザを待たせない。この別情報では障害の原因や復旧に
かかると思われる予測時間も表示する。 （ｄ）複数の端末から同一の動画データへの読みだし要
求があり、かつ両者の時刻のずれが小さい場合には、先
行する動画読みだし要求に対して、別情報を伝送するこ
とにより時刻揃えを行ない、複数の端末に対して一本の
ストリームで動画データを伝送する。これにより少ない
ストリーム数でより多くのユーザに動画データが配信可
能となる。

【００２０】

【００２１】

【００２２】

【００２３】

【００２４】

【００２５】

【００２６】

【００２７】

【００２８】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。図１は、本実施形態の動画再生
システムの概略構成を示すブロック図である。また、図
２に動画配信を中断する際の動画サーバでの処理の流れ
の概略を、図３に動画配信が中断される際の端末での処
理の流れの概略をそれぞれ示す。

【００２９】本実施形態の動画再生システムは、動画サ
ーバ１０１、複数の端末１０２、ネットワーク１０３か
らなる。動画サーバ１０１は、制御部１０５、第１の記
憶装置１０４、第２の制御部１０６を備えている。第１
の記憶装置１０４には、ユーザの要求に応じて配信する
動画データが格納される。第２の制御部１０６には、後
述する用に、ユーザの要求した動画の代りに所定時間だ
け伝送する別情報を格納する。

【００３０】端末１０２は、表示部１０７、第３の記憶
装置１０８を備えている。動画サーバ１０１は、複数の
端末１０２とネットワーク１０３を介して接続されてお
り、ユーザからの要求に対して、第１の記憶装置１０４
から動画データを取り出し、制御部１０５を介してネッ
トワーク１０３にデータを伝送する。動画データを要求
した端末１０２は、動画サーバ１０１からネットワーク
１０３経由で伝送されたデータを受信し、表示部１０７
に動画を再生する。

【００３１】本実施形態では、動画サーバ１０１の第１
の記憶装置１０４に保持された動画データには、動画の
意味的な切れ目に印が付けられている。切れ目と切れ目
の間はシーンと呼ぶ。切れ目のデータは、動画データに
直接付与されていてもよいし、補助情報として別のデー
タとして保持されていてもよい。後者の場合には、記憶
装置１０４に保持されていても記憶装置１０６に保持さ
れていてもよい。

【００３２】この意味的な動画データの切れ目は、各種
オーサリングツールによって人手で指示してもよいし、
自動シーン切り出し技術を利用してもよい。ただし、シ
ーンの途中（すなわち印が付けられた切れ目と切れ目の
間）で転送レートは変動してはならないものとし（変動
する場合には、その最大値をそのシーとにおける転送レ
ートとする）、システムは事前に転送レート情報を得ら
れるものとする。

【００３３】制御部１０５は、記憶装置１０４を制御し
ており、複数の端末からの動画要求に対して記憶装置１
０４からデータを取り出す。この複数要求に対するデー
タの取り出しのスケジューリングも制御部１０５で行な
う。制御部１０５は、例えば要求の過度の集中や障害に
より、全ての動画読み込み要求に答えるスケジューリン
グが不可能と判断した場合には、スケジューリングに失
敗した動画再生を遅らせる必要がある。また、制御部１
０５は、ネットワーク１０３のトラフィックを監視して
おり、トラフィックが多すぎて伝送が追い付かないよう
な場合にも、動画再生を遅らせる必要がある。例えば、
ネットワークの伝送容量を１ストリーム当たりの平均伝
送容量で割った値のストリーム数の８０％くらいのスト
リームを通常供給しておき、トラフィックがネットワー
ク容量の９５％を超えたところでネットワークが容量オ
ーバーするという予測を立てて、優先度の低いストリー
ムのサービスを中断する。優先度は、ストリーム固有に
当初から割り当てられている値と、その時までにサービ
スが中断された回数および時間の情報から決められる。

【００３４】前者のスケジューリングに関する原因によ
り動画再生を遅らせる必要があることが事前に判明した
場合には（ステップＳ１１）、遅らせる必要がある動画
データについて最も近い意味的な切れ目の位置まで再生
を続け（ステップＳ１２，Ｓ２２）、次にスケジューリ
ング可能となるまで、制御部１０５は記憶装置１０６に
保持された別情報を取り出してネットワーク１０３を介
して送出する。もしくは、制御部１０５は、ネットワー
ク１０３を介して、端末１０２の記憶装置１０８に対し
て代わりにデータを表示部１０７に送出するように指示
する（ステップＳ１３，Ｓ２３）。

【００３５】ここで、代わりに伝送する別情報は、コマ
ーシャル（お知らせ）、あるいは視聴者を飽きさせない
ようなクイズ、ゲーム、応募情報などであるとする。な
お、コマーシャルを代替情報として用いる場合には、物
理的な事情により伝送が困難な場合でなくても、コマー
シャルを動画提供者がプログラムに従って提供できるよ
うになる。すなわち、視聴者の嗜好に合わせた内容のコ
マーシャルを予め設定された頻度で動画の意味的な切れ
目の場所に自動挿入させることができる。また、現在動
画の配信が中断された理由や障害時の現状説明や復旧予
測時間などを表示できるようにする。また、障害発生時
に何も情報が得られない場合には、単に端末内に格納さ
れている動画データを繰り返し再生することもある。こ
のようにすることにより、希望の動画が表示されない場
合に、視聴者はその原因を知る可能性が高まる。

【００３６】後者のトラフィックに関する原因により動
画再生を送らせる必要があることが事前に判明した場合
には（ステップＳ１１）、遅らせる必要がある動画デー
タについて最も近い意味的な切れ目の位置まで再生を続
け（ステップＳ１２，Ｓ２２）、ネットワークのトラフ
ィックに空き容量ができるまで、制御部１０５はネット
ワーク１０３を介して端末１０２の記憶装置１０８にデ
ータを代わりに表示部１０７に送出するように指示する
（ステップＳ１３，Ｓ２３）。

【００３７】このように、動画の伝送が中断された場合
には、動画の伝送が中断された原因となった問題がなく
なった段階で再び当初要求された動画の伝送を再開する
（ステップＳ１４，Ｓ２４）。

【００３８】また、複数の端末から同一の動画について
伝送要求があり、しかもそれらの時間のずれが少い場合
もある。そのような場合には、要求の数だけのストリー
ムを用いて動画データを伝送するのではなく、要求の数
よりも少いストリームを割り当てられれば資源の節約に
なる。そこで、先行する動画ストリームに対して、意味
的な切れ目で要求動画の再生を中断し、複数の動画スト
リームを同期させて割り当てるストリーム数を節約す
る。ここで、中断する時間が一度に長くなりすぎないよ
うに、適度に中断時間を分割して視聴者に違和感を与え
ないように再生する。例えば、二つの動画再生要求に三
分の差があった場合、先行する動画ストリームの一度の
意味の切れ目で三分の代替データを伝送するのではな
く、例えば、一分の代替データを三回の意味的な切れ目
に分けて伝送する。

【００３９】ところで、代替情報を挿入することはサー
ビスの質（ＱＯＳ）を下げることになる。従って、この
ような場合、ユーザに不利益を与えないようにサービス
の対価を設定するのが好ましい。第一の方法として、ユ
ーザに予め代替情報が入る可能性があってもよいか否か
の選択をさせ、それに従って料金を設定する。この場合
には、代替情報が入ってもよいとしたユーザに対して
は、実際に代替情報が入っても入らなくても同一の料金
とする。もう一つの方法は、より厳密な方法であり、代
替情報が入った回数や時間を端末ごとに記録しておき、
その量によって料金を割り引く方法である。

【００４０】また、動画サーバ内の障害ではなく、動画
を配信するネットワークに障害が生じたり、ネットワー
クが容量を超過し、ネットワークの容量が超過したとい
う情報さえも流せなくなった場合には、電話線や電波
（地上波、衛星波など）を用いて動画が端末に表示され
ない状態説明、理由、修復にかかる時間などの情報を端
末に表示すると良い。この場合には、単にテキスト形式
で伝送されたものを表示してもよいし、符号化されて送
られて来た情報が指示する端末内部に格納されたデータ
（動画、静止画、音声、テキストなど）を表示しても良
い。このように動画が表示されなくなったときに直ちに
説明を行うことにより視聴者に安心感を与えることがで
きる。

【００４１】以下では、新しいストリームが転送要求を
した場合の処理およびシーンの変わり目での処理につい
て夫々説明する。転送レートは、情報を送るレートであ
り、リアルタイムに情報を送っているならば、転送レー
トと情報圧縮レートは等しい。情報圧縮レートは、アナ
ログ動画情報をデジタル動画情報に変換するときに指定
するものである。従って、エンコード時に指定した情報
圧縮レートが転送レートとなる。このため、転送レート
は既知情報である。

【００４２】ここでは、簡単のために情報圧縮レートと
して、基本圧縮率の整数倍の圧縮レートを用いるとす
る。例えば、ＭＰＥＧ１の一般的な圧縮レートである
１．５Ｍｂｐｓを基本として、３Ｍｂｐｓ，４．５Ｍｂ
ｐｓ，６Ｍｂｐｓ，．．．を用いるとする。このように
転送レートは、基本転送レートの整数倍の値をとるもの
とする。

【００４３】また、全転送容量が１５Ｍｂｐｓである場
合には、１．５Ｍｂｐｓが１０本通せることになる。
１．５Ｍｂｐｓを１スロットとすると、全転送路には１
０スロットがあることになる。例えば、４．５Ｍｂｐｓ
の情報を転送するには、３スロットを必要とすることに
なる。

【００４４】図４に、一つのタイトル中で転送レート
（動画情報圧縮率）が異なる動画の一例を示す。シーン
０，１，４はスロットを一つだけ用い、シーン２，３で
は３スロットを用い、シーン５ではスロットを２つ用い
る。

【００４５】以下、動画を受け付け、転送するアルゴリ
ズムについて説明する。ここでの転送は、記憶装置１０
４から制御部１０５への転送時にも、またネットワーク
１０３を介した転送時にも用いることができる。

【００４６】本実施形態では、転送中であったが、必要
なスロット資源が取れなくなった場合には、そのストリ
ームは空スロット待ち行列につながれる。「変数ｓ」
は、現在使用しているスロット数である。次に空スロッ
ト待ち行列につなぐ予定のストリームには、マークがつ
けられる。マークがつけられているストリームの数は、
「変数ｍａｒｋ」によって管理されている。

【００４７】新しいストリームが転送要求をした場合に
は、図５に示される処理がなされる。まず、空スロット
待ちのストリームが既にあるかどうかを調べる（ステッ
プＳ３０１）。もしあれば、新たなストリームを流すこ
とはできない。

【００４８】空スロット待ちのストリームがなければ、
現在の空スロット数があらかじめ決められたＮという定
数よりも多いかどうかを調べる（ステップＳ３０２）。
もし充分な空スロットがなければ、新しいストリームを
転送しないことにする。

【００４９】充分な空スロットがあれば、変数ｓに必要
スロット数を加えて、変数ｓを更新する（ステップＳ３
０３）。そして新しいストリームを空スロットに割り付
ける（ステップＳ３０４）。

【００５０】ここで、新しいストリームを転送開始でき
なかった場合には、一定の時間をおいて再度この処理を
実行する。次に、シーンの変わり目での処理を図６およ
び図７のフローチャートを用いて説明する。

【００５１】シーンの変わり目がどこにあるかは既知情
報であるので、シーンの変わり目よりもスケジューリン
グオーバーヘッドにあたる時間以前の時点で図６および
図７の処理を行なう。言い換えると、シーンの切れ目の
位置でのスケジューリングに間に合うように図６および
図７の判断処理を行なう。なお、ストリームの終了時の
処理も同様に図６および図７のルーチンを用いる。ただ
し、この場合には、必要なスロット数が０に変更になっ
たものとして扱う。

【００５２】このアルゴリズムは、ストリームがシーン
の切れ目に到達したときに、そのストリームを空スロッ
ト待ち行列に入れるか否か（すなわちそのストリームに
割り当てられたスロットを解放するか否か）、また空ス
ロット待ちストリームがあった場合にそれらにスロット
を割り付けるかどうかを決める。現在転送されているス
トリームが空スロット待ちになるかどうかは、関数ｆに
よって決まり、空スロット待ちストリームが空スロット
待ち行列のどの位置で待つかは関数ｇによって決まる。

【００５３】まず、自ストリームにマーク（中断すべき
ストリームにはマークが付けられる）がつけられている
かどうかを判断する（ステップＳ４０１）。ここで、自
ストリームにマークがつけられているならば、空スロッ
ト待ち行列は空ではないことになる。ただし、反対に、
自ストリームにマークがついていなかったからといっ
て、空スロット待ち行列が空であるとは限らない。

【００５４】もし自ストリームにマークがつけられてい
るならば（ステップＳ４０１）、そのストリームは中断
されるべきであるのでスロット資源を解放する必要があ
る。その処理をステップＳ４０２〜Ｓ４０９で行なう。

【００５５】自ストリームを関数ｇの値に従って空スロ
ット待ち行列につなぐ（ステップＳ４０２）。ここで、
関数ｇ（ｔ，ｄ）は、二つの引数ｔとｇを持つ。ｔはそ
のストリームが空スロット待ち行列に入ってからの滞留
時間（滞留時間の総和ではなく現在の滞留時間である）
を表し、引数ｄは過去最近Ｔ時間以内における空スロッ
ト待ち行列に滞留している時間比である。ｄの値が高い
と確率的に長い時間、空スロット待ち状態にあることを
意味する。関数ｇ（ｔ，ｄ）はｔとｄの偏微分に対して
正の値を取る。例えば、ｇ（ｔ，ｄ）＝ａ＊ｔ＊ｔ＋ｂ
＊ｄ（ａとｂは適当な正の定数）である。

【００５６】空スロット待ち行列内で、このｇ（ｔ，
ｄ）の値の高い順にソートして並べる。この特殊形がＦ
ＩＦＯであり、この場合にはｇ（ｔ，ｄ）＝ｔとなる。
しかし、この単純形のように単にｔの値だけを用いた評
価尺度ではなく、過去の実績ｄも含めた評価尺度の方が
より公平なストリームへの資源割り当てとなる。ただ
し、空スロット待ち行列の先頭のストリームに対しては
順位を変更しない。なぜならば、先頭ストリームは次に
資源を割り当てられるべきストリームとして決められて
いるからである。

【００５７】次に、ステップＳ４０３で、占有していた
スロットを解放し、現在使用されているスロット数ｓを
更新する。また、マークがつけられたストリームが一つ
空スロット待ち行列に入ったので、変数ｍａｒｋをデク
リメントする（ステップＳ４０４）。

【００５８】この結果、変数ｍａｒｋが０になったら
（ステップＳ４０５）、空スロット待ち行列の先頭のス
トリームにスロット資源を割り当て、スロット数ｓを更
新し（ステップＳ４０６）、そのストリームを空スロッ
ト待ち行列から外して活性化させる（ステップＳ４０
７）。

【００５９】もしステップＳ４０５で変数ｍａｒｋが０
にならなければ、空スロット待ち行列の先頭ストリーム
が動き出すのにはまだ充分な空スロットがないので、そ
れ以上は何もしないで処理を終了する。

【００６０】次に、ステップＳ４０５の判断で変数ｍａ
ｒｋが０となり、空スロット待ち行列の先頭ストリーム
を空スロット待ち行列から取り除いた結果、空スロット
待ち行列がまだ空でなければ（ステップＳ４０８）、空
スロット待ち行列の先頭のストリームを活性化するため
に次に休止させるべきストリームを関数ｆに従って決め
る（ステップＳ４０９）。関数ｆ（ｔ，ｄ）は、二つの
引数ｔとｄを持つ。引数ｔは、次のシーンの切れ目まで
の時間である。引数ｄは、前述のように、過去最近Ｔ時
間以内における空スロット待ち行列に滞留している時間
比である。ｄの値が高いと確率的に長い時間、空スロッ
ト待ち状態にあることを意味する。関数ｇ（ｔ，ｄ）
は、ｔとｄの偏微分に対して正の値を取る。例えば、ｆ
（ｔ，ｄ）＝ｃ＊ｔ＋ｅ＊ｄ（ｃとｅは適当な正の定
数）である。

【００６１】実際に転送中のストリームの中で、このｆ
値の低いストリームから順に、空ストリーム待ち行列の
先頭のストリームが必要とするスロット数に達するま
で、ストリームにマークを付ける。そして、変数ｍａｒ
ｋもマークを付けたストリームの数に設定する。

【００６２】もしステップＳ４０８で空スロット待ち行
列が空であれば、処理を終了する。一方、自ストリーム
にマークがつけられていない場合には（ステップＳ４０
１）、転送レートが変わるかどうかを判定する（ステッ
プＳ４１０）。これはストリームに付与された転送（圧
縮）レート情報をみればわかる。もし転送レートが変わ
らない場合には、何もせずに処理を終了させる。

【００６３】必要ストリーム数が減る場合には、不要と
なったストリームを解放し、現使用ストリーム数ｓを更
新する（ステップＳ４１１）。転送レートが増加する場
合には（ステップＳ４１０）、スロット資源を新たに獲
得する必要がある。もし、すでに空スロット待ち行列で
空スロットを待っているストリームがなく、かつ、現在
未使用のスロットが充分あるならば（ステップＳ４１
２）、必要なスロットを獲得し、現使用スロット数を更
新する（ステップＳ４１３）。自ストリームは、新たな
転送レートで転送を継続することができる。

【００６４】もし、空スロット待ち行列が空でなかった
り、資源が充分にないならば（ステップＳ４１４）、自
ストリームは空スロット待ち行列につなぎ（ステップＳ
４１４）、占有していたスロット資源を解放する（ステ
ップＳ４１５）。ステップＳ４１４で空スロット待ち行
列に自ストリームをつなぐときには、ステップＳ４０２
で述べたアルゴリズムを用いる。ステップＳ４１５では
自ストリームが占有していたスロット資源を解放し、現
使用スロット数ｓを更新する。

【００６５】その後、空スロット待ち行列が空であるか
どうかを調べ（ステップＳ４１６）、空であれば処理を
終了する。もし空でなければ、ステップＳ４０９で述べ
た手順に従ってマークのつけ直しを行なう（ステップＳ
４１７）。この結果、マークがついているものがなくな
れば（ステップＳ４１８）、空スロット待ちの先頭のス
トリームは資源を獲得できたことを意味するので、ステ
ップＳ４０６からの処理を行なう。もしステップＳ４１
８で変数ｍａｒｋが０にならなければ、空スロット待ち
行列の先頭ストリームが動き出すのにはまだ充分な空ス
ロットがないので、それ以上は何もしないで処理を終了
する。本発明は、上述した実施形態に限定されるもので
はなく、その技術的範囲において種々変形して実施する
ことができる。

【００６６】

【発明の効果】以上に説明したように、本発明によれ
ば、過負荷時、障害時、同一タイトルを複数端末から要
求があった場合にも、効率の良い動画データの伝送サー
ビスを行なうことができる。

【図面の簡単な説明】

【図１】本発明の実施の形態に係る動画再生システムの
概略構成を示すブロック図

【図２】動画配信を中断する際の動画サーバでの処理の
流れを示すフローチャート

【図３】動画配信が中断される際の端末での処理の流れ
を示すフローチャート

【図４】一つのタイトル中で転送レート（動画情報圧縮
率）が異なる例を説明するための図

【図５】新しいストリームが転送要求をした場合の処理
を示すフローチャート

【図６】シーンの変わり目での処理を示すフローチャー
ト

【図７】シーンの変わり目での処理を示すフローチャー
ト

【符号の説明】

１０１…動画サーバ １０２…端末 １０３…ネットワーク １０４，１０６、１０８…記憶装置 １０５…制御部 １０７…表示部

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】複数の動画情報が記憶されている記憶装置
   から、端末より要求された動画情報を読みだし該端末に
   配信して再生させるための動画サーバの動画再生制御方
   法において、前記 動画サーバ内に、動画の意味的な切れ目を持つ位置
   の情報を該動画と対応付けて記憶しておくとともに、動
   画の配信を一時中断した場合に前記端末に送って表示せ
   るべき別画像を予め用意しておき、前記 動画サーバは、動画再生をとぎれさせると判断され
   た場合には、前記意味的な切れ目を持つ位置まで動画を
   配信し、 その位置において動画の配信を一時中断し、 動画の配信を一時中断させた直後から、予め用意してお
   いた前記別画像を前記端末に送って表示させる ことを特
   徴とする動画再生制御方法。
2. 【請求項２】複数の動画情報が記憶されている記憶装置
   から、端末より要求された動画情報を読みだして端末に
   配信して再生させるための動画サーバの動画再生制御方
   法において、 前記動画サーバ内には、動画の意味的な切れ目を持つ位
   置の情報を該動画と対応付けて記憶しておき、 前記動画サーバは、動画再生をとぎれさせると判断され
   た場合には、前記意味的な切れ目を持つ位置まで動画を
   配信し、 その位置において動画の配信を一時中断し、 動画の配信を一時中断させた直後に、前記端末へ、該端
   末内に動画配信の中断時のために予め用意されている別
   画像を表示すべき旨の指示を送ることを特徴とする動画
   再生制御方法。
3. 【請求項３】動画情報が保持されている記憶装置からの
   データ読みだしが集中し近い将来にスケジューリングが
   できなくなることが予想された場合、ネットワークや回
   線のトラフィックを監視しトラフィック量が一定値を越
   えた場合、もしくは動画サーバ内で瞬時に回復できない
   と予測される障害の発生が検出された場合に、当該動画
   読みだし要求に対して、または複数の端末から同一の動
   画情報に対する読みだし要求があり且つ要求のあった時
   刻のずれが小さい場合に先行する動画読みだし要求に対
   して、次の意味的な切れ目を持つ位置までで動画の配信
   を中断し、端末においては次の意味的な切れ目の位置で
   再生を中断すると判断することを特徴とする請求項１ま
   たは２に記載の動画再生制御方法。
4. 【請求項４】前記読みだし要求に応じて動画を配信する
   と端末での動画再生が中断される可能性がある場合に
   は、使用料金を割り引く、もしくは動画を一時中断した
   回数や時間に応じて使用料金を割り引くことを特徴とす
   る請求項１または２に記載の動画再生制御方法。
5. 【請求項５】動画を端末に配信するのに用いるネットワ
   ークに障害が生じたかもしくはネットワーク容量を超え
   たことにより情報が伝送できない場合には、予め取り決
   められた別の伝送路を用いて動画が表示されないことに
   ついての情報を該端末に提供することを特徴とする請求
   項１または２に記載の動画再生制御方法。
6. 【請求項６】複数の動画情報を記憶するための第１の記
   憶手段と、 前記動画の意味的な切れ目を持つ位置の情報を前記動画
   と対応付けて記憶するための第２の記憶手段と、 前記動画の配信を一時中断した場合に端末に送って表示
   せるべき別画像を記憶するための第３の記憶手段と、 端末から動画情報の読みだし要求を受けた場合に、該端
   末より要求された動画情報を前記第１の記憶手段から読
   みだして該端末に配信するための手段と、 前記動画情報の配信中に動画再生をとぎれさせるか否か
   判断するための手段と、 この手段により動画再生をとぎれさせると判断された場
   合に、前記意味的な切れ目を持つ位置まで動画を配信
   し、その位置において動画の配信を一時中断し、動画の
   配信を一時中断させた直後から、前記第３の記憶手段に
   記憶されている前 記別画像を前記端末に送って表示させ
   るための手段とを備えたことを特徴とする動画サーバ。
7. 【請求項７】複数の動画情報を記憶するための第１の記
   憶手段と、 前記動画の意味的な切れ目を持つ位置の情報を前記動画
   と対応付けて記憶するための第２の記憶手段と、 端末から動画情報の読みだし要求を受けた場合に、該端
   末より要求された動画情報を前記第１の記憶手段から読
   みだして該端末に配信するための手段と、 前記動画情報の配信中に動画再生をとぎれさせるか否か
   判断するための手段と、 この手段により動画再生をとぎれさせると判断された場
   合に、前記意味的な切れ目を持つ位置まで動画を配信
   し、その位置において動画の配信を一時中断し、動画の
   配信を一時中断させた直後に、前記端末へ、該端末内に
   動画配信の中断時のために予め用意されている別画像を
   表示すべき旨の指示を送るための手段とを備えたことを
   特徴とする動画サーバ。
8. 【請求項８】動画情報が保持されている記憶装置からの
   データ読みだしが集中し近い将来にスケジューリングが
   できなくなることが予想された場合、ネットワークや回
   線のトラフィックを監視しトラフィック量が一定値を越
   えた場合、もしくは動画サーバ内で瞬時に回復できない
   と予測される障害の発生が検出された場合に、当該動画
   読みだし要求に対して、または複数の端末から同一の動
   画情報に対する読みだし要求があり且つ要求のあった時
   刻のずれが小さい場合に先行する動画読みだし要求に対
   して、次の意味的な切れ目を持つ位置までで動画の配信
   を中断することを特徴とする請求項６または７に記載の
   動画サーバ。