JP3360971B2 - ビデオ視聴者リクェストのスケジュール方法及びスケジューラ - Google Patents

ビデオ視聴者リクェストのスケジュール方法及びスケジューラ

Info

Publication number
JP3360971B2
JP3360971B2 JP14713895A JP14713895A JP3360971B2 JP 3360971 B2 JP3360971 B2 JP 3360971B2 JP 14713895 A JP14713895 A JP 14713895A JP 14713895 A JP14713895 A JP 14713895A JP 3360971 B2 JP3360971 B2 JP 3360971B2
Authority
JP
Japan
Prior art keywords
video
requests
queue
request
outstanding performance
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 - Lifetime
Application number
JP14713895A
Other languages
English (en)
Other versions
JPH0870446A (ja
Inventor
フィリップ・シールン・ユウ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH0870446A publication Critical patent/JPH0870446A/ja
Application granted granted Critical
Publication of JP3360971B2 publication Critical patent/JP3360971B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17327—Transmission or handling of upstream communications with deferred transmission or handling of upstream communications

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、ビデオ・オン・デマン
ド・システムにおけるパフォーマンス・リクェストのス
ケジュール方法及びそのスケジューラに関する。
【０００２】
【従来の技術】ビデオ・オン・デマンド(VOD)システム
では、多くの視聴者がリクェストするホット・ビデオ
（即ち映画又は他のプログラム）がしばしば存在する。
システムのスループットを増加させるために、バッチ処
理（同一ビデオをリクェストしている視聴者に対して一
つのビデオ・ストリームを共有させること）がしばしば
利用される。
【０００３】システム負荷によっては、ビデオ・リクェ
ストに直ちに応答できないことがある。視聴者は、通
常、少しばかり（例えば、3〜5分）の遅れに対しては容
認してもらえるが、それ以上長い遅れは、典型的には、
何人かの視聴者を逃がして（即ち、リクェストした後、
又は全くリクェストもせずにシステムから抜け出して）
しまう。視聴者を逃がしてしまう確率は、遅れの長さの
増大と共に増大する。
【０００４】視聴者計画に対する通常的な処理方法は、
ファースト・カム・ファースト・サーブ（first-come-f
irst-served(FCFS))方式である。この方式では、全ての
ビデオ・リクェストが一つのリクェスト・キューに併合
される。ストリーム機能が利用可能となると、リクェス
ト・キューの先頭のリクェストにサービスを行う。更
に、バッチ処理を支援するために、同一ビデオに関する
次の全てのリクェストもこのストリームによりサービス
させる。
【０００５】他に代わるものでは、各ビデオについて別
のリクェスト・キューを保持し、かつ次のショー実施に
ついて最も長いキューを有するビデオを選択することで
ある。これは、ロンゲスト・キュー・ファースト(LQF)
方式と呼ばれる。更に他の解決方式は最もホットな（頻
繁なリクェストの）ビデオに対して周期的な（例えば５
分毎の）ショー実施を提供するとである。周期的なショ
ー実施により対応されていない他のリクェストに対して
は、FCFSのような他の計画機構を用いてもよい。
【０００６】前述のように、待ちリクェストは、待ち時
間がリクェストする視聴者の許容限度を超えるときは、
キューから離脱する恐れがある。この視聴者の喪失（し
ばしば取り消しと呼ばれる）は好ましくない。ビデオ・
スケジュール方式の選択はバッチ処理量及び視聴者の喪
失量に大きな影響を与える恐れがある。FCFS方式バッチ
処理要素を計算に入れておらず、一方LQF方式は待ちリ
クェストにより既に受けた待ち時間を無視する。周期的
なショー実施（単独で用いた場合）はダイナミックな負
荷の変動に対応するために必要な柔軟性がない。
【０００７】
【発明が解決しようとする課題】従って、本発明の目的
は、バッチ処理を容易にしてVODシステムの収益を最大
化するように、視聴者の遅れ許容限度を明確に利用した
許可制御に対するビデオ・リクェストのスケジュール方
法及びスケジューラを提供することにある。
【０００８】
【課題を解決するための手段】各視聴者は同一の料金を
支払い、収益はサポート可能な視聴者と共に増加するも
のと仮定する。バッチ処理を容易にする遅れ許容限度を
利用するために、スケジュール決定の際には現にショー
実施をしているビデオの完了スケジュールを考慮にいれ
る。
【０００９】以上のことから、VODスケジューラは少な
くとも一つの映画に関する未処理パフォーマンスのキュ
ーを保持する。ストリーム機能が利用可能になると、映
画を直ちにスケジュール化するよりも、スケジューラが
未処理パフォーマンス・リクェストのうちの最も長い待
ちリクェストの最大待ち許容限度時間が過ぎる直前ま
で、ビデオのパフォーマンスを遅らせる。その間に、付
加的なストリームはキューを併合させることができる。
パフォーマンスが始まると、キュー上の全てのパフォー
マンス・リクェストは単一のストリームからサービスさ
れる。
【００１０】１以下の図において同一番号により示され
ている要素は、同一要素を示す。
【００１１】
【実施例】
ａ．概要 ここで「収益に基づくスケジューラ」には、２つの基本
的な考えが存在する。その第１の考えは、ホット・ビデ
オ（頻繁にリクェストされるビデオケジュールを視聴者
の許容限度時間内で可能とする限り遅延させる方式であ
る。これは、付加的な遅れの最中に、同一のビデオに関
する他のリクェストがいくつか到着することに基づいて
いる。そのときは、他のリクェストをバッチして最初の
視聴者のリクェストと共に、共通のビデオ・ショー実施
（パフォーマンス）を視聴させるさせることができる。
最初の視聴者リクェストを余り長く遅らせると、最初に
リクェストしていた視聴者を失う結果となるのは間違い
ない。
【００１２】第２の考えは、長い待ちをもたらす重負荷
のために視聴者の喪失が避けられないのであれば、コー
ルド（頻繁にはリクェストしない）ビデオ視聴者は喪失
してしまってもよいという考え方である。これは、Ｍ視
聴者のバッチにサービスをすることによる収入が一人の
視聴者に対するショー実施の収入のＭ倍であることによ
っている。いずれにしろ、物理的に１つのストリーム機
能が消費される。従って、バッチ・ショー実施に関する
収益は遥かに高い。
【００１３】収益に基づくスケジューラは個別的な２つ
の待ちキューを保持する。第１のものはＨキューと呼ば
れ、予め指定されたホット・ビデオ、及び現に多数の待
ちリクェストを有する他のビデオのパフォーマンスを待
機しているリクェストを含む。各ホット・ビデオにつき
一つの、多数のサブキューとして、Ｈキューを実行する
ことができる。第２のものはＣキューと呼ばれ、コール
ド・ビデオに対する他の待ち視聴者を含む。ビデオが
「ホット」であるか、又は「コールド」であるかは、デ
ータベースに記憶され、前の期間（例えば前の日）に受
け取ったリクェストに基づいたシステム即ちシステム・
オペレータにより決定される。公正さを保持するため
に、Ｃキューにおける長い待ちリクェストをＨキューに
移動させることができる。更に、このスケジューラは現
在見せているビデオに関する完了時間のリストを保持し
ている。
【００１４】視聴者の待ち許容限度が小さな遅れ（例え
ば、３〜５分）であると仮定する。その待ち許容限度時
間内では、視聴者がその待ち時間量内で離れてしまう確
率は無視できると仮定する。長い遅れでは、何人かの視
聴者は離れて行くと思われる。これを説明するために、
遅れ許容限度期間ｉは、ユーザ待ち許容限度と、実際に
リクェストしたビデオが開始するまでに掛かる時間との
両方を考慮している。従って、遅れ許容限度期間ｉは、
実際には、ユーザ遅れ許容限度時間よりいくらか短い。
換言すれば、遅れ許容限度期間ｉが経過したときは、ユ
ーザの実際の遅れ許容限度時間が経過するまでに、リク
ェストしたビデオを開始するために残された時間は十分
（例えば、１〜２秒）ある。
【００１５】このスケジューラは、以下の事象：ストリ
ーム完了、新しいリクェストの到着、又はその待ち許容
限度に達するＨキューにおける初期のリクェストのうち
のいずれかが発生する度に、呼び出される。そうでない
ときは、スケジューラは待ち（不活性）状態にある。こ
れは以下のように作動する。
【００１６】ステップ１： 現在利用可能なストリー
ム、及び将来、完了するようにスケジュールされたスト
リームが与えられていると、スケジューラが呼び出され
たときは、Ｈキュー上の各リクェストをその遅れ許容限
度期間ｉ内にスケジュールすることができる。ただし、
そのうちのｋを除き、ｋ≧１は、以下で説明されチュー
ニング・パラメータである。イエスのときは、スケジュ
ーラはステップ２を実行する。ノーのときは、スケジュ
ーラはステップ４を実行する。
【００１７】ステップ２： これは十分ストリーム機能
が利用可能な場合を表す。Ｃキューが空きのときは、ス
テップ６に行く。
【００１８】ステップ３： Ｃキューが空でないとき
は、スケジューラはＣキューからの初期のリクェストを
取り上げて、これをスケジュールする。次に、スケジュ
ーラは終了に行き、待機状態に再び入る。
【００１９】ステップ４： これは限定されたストリー
ム機能を有する場合である。スケジューラはセットＥを
決定し、このセットＥはそれらの遅れ許容限度期間を超
えた、又は次のスケジュール例若しくはストリーム完了
時間のときにそれらの遅れ許容限度期間を超えることに
なる、未処理リクェストを有するビデオ・セットであ
る。
【００２０】ステップ５： 待ち視聴者の遅れ許容限度
期間を何人か超えたとき、又は次のスケジュール例によ
り待ち時間上の許容限度を超えることになるときは、ス
ケジューラは、Ｈキューにおける最初のリクェストによ
るビデオを取り上げてスケジュールする。タイとなると
きは、スケジューラは最も長いキューを有するビデオを
取り上げてタイでなくなる。次いで、ステップ７へ行
く。
【００２１】ステップ６： 使用していないストリーム
機能が十分に存在するときは、スケジューラはＨキュー
における最初のリクェストを有するビデオを取り上げて
スケジュールして、終了に行く。この説明おいて、用語
の「十分」とは、全ての未処理の全てのＣキュー及びＨ
キューのリクェストと共に、全しきい値時間期間内に受
け取ることを期待された全てのＣキュー及びＨキュー・
リクェストをスケジュールするために使用していないス
トリーム機能が十分存在することを意味する（例えば、
既知の次のスケジュール例）。十分に存在しないとき
は、ステップ７へ行く。
【００２２】ステップ７： スケジューラは終了に行
き、待機状態に再び入る。
【００２３】ｋ＞１のときは、現時点では視聴者を有し
ないかも知れないが、その後に多数の視聴者を得るかも
知れないホット・ビデオに適応させるように、付加的な
いくらかの機能を予約することができる。ｋ値は、現
在、Ｈキューに含まれないホット・ビデオの機能とすべ
きである。
【００２４】ステップ５において、その代りは最長のキ
ューに関連されるビデオを選択することである。
【００２５】ステップ７の意図は、視聴者待ち許容限度
内で可能とする限り、スケジュール処理を遅延させるこ
とである。例えば、時間ｔにおいて、スケジューラは、
Ｈキューにおける特定のビデオＶ１に対してＮリクェス
ト存在することが判る。ただし、最初のリクェストはt-
30秒で到着する。このシステムにおけるリクェストに対
する待ち許容限度は２分である（これは、遅れ許容限度
期間ｉが多分１分58秒であることを意味する）。Ｃキュ
ーには（異なるビデオＶ２のために）他のリクェストが
存在する。次に利用可能なストリームＳ２はt+3分で完
了するようにスケジュールされる。スケジューラは（Ｃ
キューからの）コールド・ビデオVｉをスケジュールす
ることはない。なぜならば、このようにすることはホッ
ト・ビデオVｉに対するリクェストを損失させることに
なるからである。従って、スケジューラは待機状態に入
り、t+1分28秒に再び呼出される。この時点で、スケジ
ューラはストリームS1上のビデオV１のパフォーマンス
を開始する。i（１分58分）が経過しているので、ビデ
オは最初のリクェスト者に対する待ち許容限度の最後の
瞬間にビデオが示される。このようにして、スケジュー
ラが待機している間に、リクェストが１分58分期間に到
着するビデオV１の付加的なリクェスト者を、ストリー
ムS１上の映画を見るように、それが開始する前にスケ
ジュールすることができる。
【００２６】多重リクェストが遅れ許容限度期間を超え
るステップ７において、他の実施例では、スケジュール
したパフォーマンス終了を遅延させる代わりに、最初の
リクェスト又は最長のキューに関連したビデオをスケジ
ュールすることにある。
【００２７】ｂ．詳細な説明 図１はビデオ・サーバ100のブロック図であり、ビデオ
・データ（映画、又は他の動く映像又は映像音声パフォ
ーマンス）をディスク102に記憶し、かつリクェストの
ときはネットワーク104を介してエンド・クライアント
・ステーション103に送信される。更に、ビデオ・サー
バ100は、ワーキング・データ及びビデオ・サーバ30用
のプログラム・コードを記憶する他のディスク（図示な
し）を含み、またビデオ・テープ・プレーヤ、ディスク
102に映画をロードすることができるジュークボックス
のような他のメモリデバイスを含めることができる。
【００２８】ビデオ・サーバ100用のプログラム・コー
ドには、サーバ・メイン・コントロール・プログラム、
ビデオ・スケジューリング・プログラム、カストマー使
用トラッキング・プログラム、通常の通信、入出力及び
バッファ管理プロセスのような処理が含まれる。ビデオ
・サーバ100には、メイン・コントロール・プログラム
によるプログラムを実行するプロセッサ(cpu) 101、及
びビデオの複数部分の一時記憶に用いるメモリ・バッフ
ァ105が含まれている（何人かのユーザをディスク102よ
りもメモリ・バッファ105からサービスできるようにす
る）。更に、メモリ・バッファ105を用いて、視聴者が
休止している間にディスクから流れ出すビデオの複数部
分用の一時メモリを提供することにより、休止／再開リ
クェストを取り扱うこともできる。処理は、スケジュー
ラ106以外に、典型的にはVODシステムに用いる通常型式
のものでよい。
【００２９】ビデオ・サーバ100は、サポートすべきビ
デオ・ストリームの数のために十分な性能の任意のプロ
セッサを用いて実施されてもよい。例えば、小容量のビ
デオ・サーバはRISCシステム/6000TMシステムを用いて
実施されてもよく、一方大容量サーバはESシステム/900
0TMシステムを用いて実施されてもよい（いずれのシス
テムもも米国ニューヨーク州アーモンクのインターナシ
ョナル・ビジネス・マシンズ・コーポレーションから入
手可能である）。ディスク102は通常的な任意のディス
クのもの又はディスク・アレーのものでよい。エンド・
クライアント・ステーション103は、例えばファイバ・
オプティク・ネットワーク又は通常双方向ケーブル・ネ
ットワークでもよい。エンド・クライアント・ステーシ
ョン103はセット・トップ・ボックス(set-top box)とし
て実施されてもよい。
【００３０】スケジューラ106はリクェストしたビデオ
についてのパフォーマンスをスケジュールする結果とな
る多数のタスクを実行する。本発明の実施例において
は、エンド・クライアント・ステーション103からのビ
デオ・リクェストを受け取ると、スケジューラ（収益に
基づくスケジューラ）106は、適当なリクェスト・キュ
ー：Ｈキュー106a又はＣキュー106bにリクェストを登録
する。リクェストがスケジュールされると、完了時間は
将来のスケジューリングを支援するように完了時間リス
ト106cによりトラッキングされる。
【００３１】ここで図２を参照すると、本発明の一実施
例によるリクェスト・キュー用のデータ構造が示されて
いる。リクェスト・キューはＨキュー106a及びＣキュー
106bからなる。Ｈキューは、ホット・ビデオ、及び１よ
り長いキュー長を有するか、又は長過ぎる待ち時間を有
する他のビデオである各ビデオについて一つの多数のサ
ブシーケンスを含む。各リクェストにとって、リクェス
ト者id(Ri)及び到着時間(ti)はシーケンスに保持され
る。コールド・ビデオに対するリクェストをトラッキン
グするＣキューでは、到着順により単一のキューが保持
される。各リクェストのために、リクェスト者id(Ri)、
リクェストされたビデオ(Vi)及び到着時間(ti)はキュー
に保持される。
【００３２】図２において、Ｈキューは、リクェストを
キューに登録した３つのホット・ビデオVa、Vb及びVkを
有する。ホット・ビデオVa及びVbはそれぞれ２つのリク
ェストをキューに登録しており、一方ＨキューVkは一つ
のキューのみを登録している。Ｃキューには、２つのリ
クェストがキューに登録されている。
【００３３】ここで図３を参照すると、図１の与えられ
たリクェストの取り扱い、収益に基づくスケジューラ10
6を概要的に示されている。
【００３４】ステップ205において、ビデオ・リクェス
トの到着を検出すると、スケジューラ106を呼び出す。
【００３５】次に、ステップ210において、リクェスト
を適当なリクェスト・キュー（Ｈキュー又はＣキュー）
に登録する。
【００３６】ステップ215において、利用可能なビデオ
・ストリームをチェックする。現在、利用可能なストリ
ーム機能がないときは、ステップ220において、スケジ
ューラは終了に行く。他方、利用可能なストリーム機能
があるときは、ステップ225において、スケジューラは
図４のビデオ・ストリーム・スケジューリング・タスク
を実行して何人かの視聴者のためにビデオをスケジュー
ルする。
【００３７】ビデオをスケジュールしたときは、ステッ
プ230において、ビデオを全てのリクェストしている視
聴者に多重割り付けする。
【００３８】ステップ235において、ビデオを完了し、
対応するビデオ・サーバを開放して待ちリクェストのス
ケジュールに利用可能となる。
【００３９】ステップ240において、リクェスト・キュ
ーをチェックする。リクェスト・キューが空のときは、
ステップ245において、スケジューラは終了に行く。他
方、待ちリクェストがあるときは、ステップ225におい
て、再び図４のビデオ・ストリーム・スケジューリング
・タスクを実行してビデオ・リクェストをスケジュール
する。
【００４０】図３は個別的なリクェストの取り扱いサイ
クルをトラッキングしているが、実際において、図３の
多くのステップは、スケジューラが異なるリクェストを
取り扱う際に並行に発生し得ることを理解すべきであ
る。これは、図５〜図７に最もよく示されている。
【００４１】図５〜図７は収益に基づくスケジューラに
おいて取り扱う事象のフローチャートである。各タスク
(図5、図6及び図7)は異なるリクェストを並行して実行す
ることができるが、しかし、ビデオ・ストリーム・スケ
ジューラは直列化する点である。即ち、これは、一度に
１つのタスク即ち事象のみにより、ビデオ・ストリーム
・スケジューラを呼び出し、呼び出せば実行して完了さ
せる。
【００４２】図５は収益に基づくスケジューラにより取
り扱うビデオ・リクェストのフローチャートである。
【００４３】視聴者からビデオに関する新しいパフォー
マンスのリクェストが出される度に、ステップ502にお
いて、スケジューラは、そのリクェストがVODシステム
に到着するのを検出する。
【００４４】次に、ステップ504において、スケジュー
ラは、リクェスト(Hキュー又はＣキュー）のために適当
なキューを決定し、従ってリクェストを正しいキューに
登録する。リクェストがホット・ビデオ又は現在Ｈキュ
ーにあるビデオのうちの一つに対するものであるとき
は、これをＨキューに挿入する。他方、スケジューラ
は、リクェストしたビデオがＣキューに既に現れている
か否か、即ちリクェストしたビデオがそれについて既に
キューを有するかをチェックする。イエスのときは、ス
ケジューラは新しいリクェスト、及びそのビデオに対す
る他の待ちリクェストをＨキューに移動させる。他方、
ビデオがＣキューに現れなかったときは、スケジューラ
は新しいリクェストをＣキューに登録する。
【００４５】次いで、ステップ506において、スケジュ
ーラは、サーバに利用可能なストリーム機能が存在する
か否かを判断する。リクェストにサービスをするために
利用可能な機能が存在しないときは、ステップ508にお
いてスケジューラは終了する。ここで、現在送出中のビ
デオが完了し、かつ関連するストリーム機能を開放する
までは、リクェストをスケジュールすることはできな
い。サーバが利用可能なストリーム機能を有するとき
は、スケジューラは図４のビデオ・ストリーム・スケジ
ューリングを呼び出す。
【００４６】図６は収益に基づくスケジューラによるビ
デオ完了取り扱いのフローチャートである。
【００４７】ステップ512において、スケジューラがビ
デオの完了を検出する。ビデオは、スケジュールした終
了時間までのパフォーマンスを終了することにより、又
はビデオの全ての視聴者により、完了してビデオを終了
すること（パフォーマンスを終結すること）ができる。
【００４８】ステップ５１４において、スケジューラは
ストリーム機能を「利用可能」であるとしてマークを付
けることにより開放する（ビデオ・サーバがステータス
・テーブルにより便宜的に各ストリーム機能の使用即ち
利用可能ステータスをトラッキングする）。
【００４９】ステップ516において、スケジューラはリ
クェスト・キューをチェックしてリクェスト・キューが
空きか（即ち、未処理リクェストがＨキューか、又はＣ
キューに存在するか）否かを判断する。リクェスト・キ
ューが空きのときは、ステップ518において、スケジュ
ーラは終了に行く。他方、リクェスト・キューが空でな
い（待ちリクェストが存在する）ときは、ステップ520
において、スケジューラは図４のビデオ・ストリーム・
スケジューリング・タスクを呼び出す。
【００５０】図７は収益に基づくスケジューラが取り扱
う遅れ許容限度期間の経過のフローチャートである。
【００５１】ビデオの遅れ許容限度期間が経過したとき
は、これがステップ522において検出される。これは、
例えば、Ｈキューにおけるリクェストの遅れ許容限度期
間が経過したときは、遅れ許容限度期間に対して、又は
割込を発生するようにプログラムされている期間タイマ
のような装置と連係して、Ｈキュー・リクェストの待ち
時間を規則的にチェックするソフトウェアにより、行う
ことができる。
【００５２】スケジューラがＨキューにおけるリクェス
トの遅れ許容限度期間が経過したことを検出すると、ス
テップ524において、図４のビデオ・ストリーム・スケ
ジューリング・タスクを呼び出す。
【００５３】ここで、図４を参照すると、ビデオ・スト
リーム・スケジューリング・タスクが更に詳細に示され
ている。以下の事象：ストリーム完了、新しいリクェス
トの到着、又はその待ち許容限度に達するＨキューにお
いて初期のリクェストのうちのいずれか一つが発生する
度に、ビデオ・ストリーム・スケジューリング・タスク
を呼び出す。他方、このビデオ・ストリーム・スケジュ
ーリング・タスクは待ち（不活性）状態にある。
【００５４】ステップ300において、スケジューラは、
まず、ｋストリームを除いた後、現在、利用可能なスト
リーム、及び将来に完了することがスケジュールされて
いるストリームを用いて、遅れ許容限度期間内にＨキュ
ーの全てのリクェストをスケジュールすることができる
か否かを判断する。遅れ許容限度期間内にＨキューの全
てのリクェストをスケジューラできないときは、ステッ
プ305において、スケジューラは、スケジュールされた
次のストリーム完了時間で遅れ許容限度期間を超えるこ
とになる組のビデオ・リクェストについて判断する。こ
の組のビデオ・リクェストはセットＥと呼ばれる。
【００５５】ステップ310において、スケジューラは、
セットＥにおけるリクェストが遅れ許容限度期間を超え
たか否かを判断する。セットＥにおいてリクェストが遅
れ許容限度期間を超えたときは、ステップ315において
最初のリクェスト到着時間を有するビデオをスケジュー
ルし、そのビデオに関連した全ての未処理リクェストを
キューから除去する。次いで、ステップ345において、
タスクは、他の事象がタスクを呼び出すことになるまで
（即ち、Ｈキューにおいて次の最初のリクェストが遅れ
許容限度期間、新しいリクェストの到着、又はビデオの
完了となるまで）、終了に行く。
【００５６】セットＥにおけるリクェストに待ち許容限
度期間を超ええいるものがないときは、ステップ345に
おいて、タスクはＨキューにおける最初のリクェストが
遅れ許容限度期間になるまで、又は他の事象を呼び出す
まで（即ち、新しいリクェストの到着、又はビデオの完
了となるまで）終了に行く。
【００５７】待ち許容限度内に全てのＨキューをスケジ
ュールすることができるときは、ステップ325におい
て、スケジューラは、Ｃキューが空であるか否かをチェ
ックする。Ｃキューが空でないときは、ステップ330に
おいて、Ｃキューからの最初のリクェストをスケジュー
ルする。次いで、ステップ345において、タスクは、Ｈ
キューにおける最初のリクェストが遅れ許容限度期間に
到着するまで、又は他の事象がタスクを呼び出すまで
（即ち、新しいリクェストの到着、又はビデオの完了と
なるまで）、終了に行く。
【００５８】ステップ325において、Ｃキューが空きで
あると判断すると、ステップ335において、スケジュー
ラは使用されていない多数のビデオ・ストリームがある
か否かをチェックする。イエスのときは、ステップ340
において、Ｈキューにおいて最初のリクェストに関連す
るビデオをスケジュールし、ステップ345において、Ｈ
キューにおける最初のリクェストが遅れ許容限度期間に
到着するまで、又は他の事象がタスクを呼び出すまで、
終了に行く。
【００５９】待ち時間上で喪失機能が利用可能なとき
は、ダイナミック・プログラムのような数学的な最適化
問題（F. Hiller and G. Lieberman in Operations Res
earch,Second Edition (1974), Holden-day, pages 248
〜275) を公式化して視聴者の喪失数を最小化するよう
に、又はビデオ・サーバの収益を最大値化するように、
次のビデオを選択させることができる。
【００６０】非対話VODシステムにおいて、休止−再開
動作を可能にする対話VOD環境であっても、ストリーム
完了が常時既知であるが、休止したストリームの再開を
支援するためにバッファを用いることにより、完了時間
を確実にさせることができる。このようなシステムにお
いて、視聴者がビデオ・パフォーマンスを休止するとき
は、視聴者にサービスをするストリームの内容はバッフ
ァに置かれる。同一のストリームからビデオをサービス
される他の視聴者は、バッファのない元のストリームか
ら映画を見続ける。休止した視聴者が再開すると、視聴
者はバッファからサービスされる。従って、元の（ディ
スクから発生する）ストリームのストリーム完了時間は
一定のままである。
【００６１】スケジューラに関連する他の発行は許可制
御である。スケジュール方針が与えられると、許可制御
処理を提供することによりリクェスト者に対して待ち時
間に関する粗い予測を提供するので、リクェスト者のそ
れぞれが最初にビデオを待つか否かの判断が可能であ
る。特に長い待ちであり、予測が過小評価になったとき
は、それでも視聴者が気持ちを変えて、ショー実施前に
立ち去ることがあり得る。
【００６２】まず、ホット・ビデオのリクェストが到着
し、そのビデオに対する他の待ちリクェストが存在する
場合を考える。ホット・ビデオ・リクェストが同一ビデ
オに関する他のリクェストによりバッチされると、その
開始時間はこれらのリクェストと同一である。リクェス
トしたビデオに対して他の視聴者の待ちがないときは、
許可制御処理は、待ち許容限度期限内にリクェストをス
ケジュールすることができるか否かを判断するために必
要である。イエスのときは、リクェストは最終可能例よ
り遅くならないようにスケジュールされるが、依然とし
てユーザ待ち時間許容限度を満足させている。他方、リ
クェストは、現在のＨキューの全てのリクェストを満足
させた後に、次に利用可能なストリーム完了時間にスケ
ジュールさせる。
【００６３】コールド・ビデオ・リクェストの場合は、
スケジューラがこのリクェストを単にフィラーとして使
用することにより、利用可能なストリーム機能を使い切
るので、予測は更に困難になると思われる。次のＨキュ
ー・リクェストは、到着時点で想定していた遅延より、
Ｃキュー・リクェストを更に遅延させる恐れがある。
【００６４】この場合には、許可制御により得られる予
測待ち時間をある拡大係数により乗算することができ
る、又はより大まかな形式、例えば5分の代わりに5〜10
分のように提供することができる。その代りとして、許
可制御は、新しい予測の待ち時間を待っている視聴者に
助言し続けることができる。ショー実施を待ちたいコー
ルド・ビデオ視聴者に対して何らかの公正さを維持する
ために、Ｈキューに対して予測した待ち時間上の上限を
超えてしまったＣキュー・リクェストを移動させること
ができる。
【００６５】前述の実施例では、与えられたシステム上
で複数のリクェスト者は同一の待ち許容限度時間をそれ
ぞれ有し、従って全システムに対して唯一の待ち許容限
度期間が存在するということを仮定した。その代りとし
て、異なる複数リクェスト又は異なる映画に対する複数
のリクェストに異なる待ち時間（従って、異なる遅れ許
容限度期間）を割り付けることができる。
【００６６】ここで、好ましい実施例により本発明を説
明したが、当該技術分野に習熟する者には種々の変形及
び改良が考えられる。従って、１例として、かつ限定と
してではなく好ましい実施例を提供したことを理解すべ
きである。本発明の範囲は請求の範囲により定義され
る。
【００６７】まとめとして、本発明の構成に関して以下
の項を開示する。
【００６８】（１）ビデオ・オン・デマンド・サービス
のためのビデオ視聴者リクェスト方法において、前記ビ
デオ視聴者リクェストのスケジュールは最大待ち許容時
間を有し、映画に対する複数の未処理パフォーマンス・
リクェストのキューを保持するステップと、サーバ・ス
トリーム機能が何時利用可能になるかを判断するステッ
プと、複数の未処理パフォーマンス・リクェストのうち
で最も長い待ちのリクエストの最大待ち許容限度時間が
経過する直前まで、映画のスケジュールを遅延させるス
テップとを含む、ビデオ視聴者リクェストのスケジュー
ル方法。
【００６９】（２）更に、前記遅延中に、前記映画に対
する付加的なリクェストをキューに登録するステップ
と、共通ビデオ・ストリームから前記付加的なリクェス
トにサービスをするステップとを含む、前記（１）に記
載のビデオ視聴者リクェストのスケジュール方法。
【００７０】（３）更に、ビデオ・サーバから前記視聴
者の位置における受信装置へ前記共通ビデオ・ストリー
ムを送信するステップを含む、前記（１）に記載のビデ
オ視聴者リクェストのスケジュール方法。
【００７１】（４）ビデオ・サーバにより提供されるビ
デオ・オン・デマンド・サービスに対するビデオ視聴者
リクェストのスケジュール方法において、前記ビデオ視
聴者リクェストは最大待ち許容時間を有し、映画に対す
る複数の未処理パフォーマンス・リクェストのキューを
ビデオ・サーバのところで保持するステップと、前記未
処理パフォーマンス・リクェストのために最大待ち許容
時間を決定するステップと、サーバ・ストリーム機能が
何時利用可能となるのかを判断するステップと、複数の
未処理パフォーマンス・リクェストのうちで最も長い待
ちのリクエストによる最大待ち許容限度時間を超える直
前まで、前記ストリーム機能のうちの一つから前記キュ
ーにある全ての未処理パフォーマンス・リクェストにサ
ービスをするステップとを含む、ビデオ視聴者リクェス
トのスケジュール方法。
【００７２】（５）ビデオ・サーバにより提供されるビ
デオ・オン・デマンド・サービスに対するビデオ視聴者
リクェストのスケジュール方法において、前記ビデオ視
聴者リクェストは最大待ち許容時間を有し、多数の映画
のそれぞれに対する複数の未処理パフォーマンス・リク
ェストのキューをビデオ・サーバのところで保持するス
テップと、サーバ・ストリーム機能が何時利用可能とな
るのかを判断するステップと、前記最大待ち許容限度時
間を経過する直前まで、複数の未処理パフォーマンス・
リクェストのうちで最も長い待ちのリクエストを有する
キューについて前記未処理パフォーマンス・リクェスト
にサービスをするステップと、を含む、ビデオ視聴者リ
クェストのスケジュール方法。
【００７３】（６）前記第１のグループのキューは頻繁
にリクェストされる映画について保持され、かつ前記第
２のグループのキューはより頻度の低いサービスの映画
について保持され、かつ前記第２のグループのキュー
は、キューの最も長い待ちのリクェストに対する最大待
ち許容時間が経過する前に、前記第１のグループのキュ
ーにおける全ての未処理パフォーマンス・リクェストに
サービス可能となるまで、サービスされない、前記
（５）に記載のビデオ視聴者リクェストのスケジュール
方法。
【００７４】（７）映画の複数の未処理リクェストが最
大待ち許容時間を有し、前記最大待ち許容限度時間後
は、複数のリクェスト者が複数のリクェストを破棄する
ことになる型式のビデオ・オン・デマンド・システムで
用いるスケジューラにおいて、映画に対する複数の未処
理パフォーマンス・リクェストを保持するキュー手段
と、前記パフォーマンス・リクェストのうちの最大の待
ちのリクエストの待ち時間を判断する手段と、前記複数
の未処理パフォーマンス・リクェストのうちで最も長い
待ちが前記最大待ち許容限度時間を超える直前に、前記
ストリーム機能のうちの一つから前記キュー内の全ての
未処理パフォーマンス・リクェストにサービスをする手
段とを含む、スケジュール装置。
【００７５】（８）キューは頻繁にリクェストされる映
画についての第１のグループのキュー、及びより頻度の
低いサービスの映画についての第２のグループのキュー
を保持する手段を含み、前記サーバ手段は、前記キュー
の最も長い待ちリクェストのための最大待ち許容時間が
経過する前に、前記第１のグループの各キューにおける
全ての未処理パフォーマンス・リクェストにサービス可
能となるまで、前記第２のグループのキューにサービス
をしない、（７）に記載のスケジュール装置。
【００７６】
【発明の効果】本発明によれば、VODスケジューラが少
なくとも一つの映画についての未処理パフォーマンスの
キューを保持し、ストリーム機能が利用可能になると、
映画を直ちにスケジュール化するよりも、スケジューラ
が未処理パフォーマンス・リクェストのうちの最も長い
待ちリクェストの最大待ち許容限度時間が過ぎる直前ま
で、ビデオのパフォーマンスを遅らせ、その間に付加的
なストリームがキューを併合させ、パフォーマンスが始
まると、キュー上の全てのパフォーマンス・リクェスト
が単一のストリームからサービスされるように構成され
ているので、バッチ処理を容易にしてVODシステムの収
益を最大化することができる。
【図面の簡単な説明】
【図１】マルチメディア・サーバのブロック図である。
【図２】リクェスト・キューを保持するために収益に基
づくスケジューラにより用いられるデータ構造である。
【図３】本システムにおいて取り扱うリクェストの概要
を示すフローチャートである。
【図４】収益に基づくスケジューラのビデオ・ストリー
ムのフローチャートである。
【図５】収益に基づくスケジューラにおいて取り扱う事
象のフローチャートである。
【図６】収益に基づくスケジューラにおいて取り扱う事
象のフローチャートである。
【図７】収益に基づくスケジューラにおいて取り扱う事
象のフローチャートである。
【符号の説明】
１００ ビデオ・サーバ １０１ ＣＰＵ １０３ エンド・クライアント・ステーション １０５ メモリ・バッファ １０６ スケジューラ
───────────────────────────────────────────────────── フロントページの続き (72)発明者 フィリップ・シールン・ユウ アメリカ合衆国10514 ニューヨーク州、 チャッパカ、ストーノウェイ 18 (56)参考文献 特開 平６−153198（ＪＰ，Ａ)

Claims (8)

    (57)【特許請求の範囲】
  1. 【請求項１】ビデオ・オン・デマンド・サービスのため
    のビデオ視聴者リクエストのスケジュール方法であっ
    て、前記ビデオ視聴者リクエストは最大待ち許容時間を
    有し、 １の映画に対する複数の未処理パフォーマンス・リクエ
    ストのキューを保持するステップと、 前記複数の未処理パフォーマンス・リクエストのうちで
    最も長く待っているものの前記最大待ち許容限度時間が
    経過する直前まで、前記１の映画のスケジュールを遅延
    させるステップと、 視聴者の受信装置へ前記１の映画についての共通ビデオ
    ・ストリームを送信するステップとを含む、ビデオ視聴
    者リクエストのスケジュール方法。
  2. 【請求項２】前記遅延中に、前記１の映画に対する付加
    的なリクエストをキューに登録するステップと、前記共
    通ビデオ・ストリームを前記付加的なリクエストに対し
    てサービスするステップとをさらに含む、請求項１に記
    載のビデオ視聴者リクエストのスケジュール方法。
  3. 【請求項３】ビデオ・オン・デマンド・サービスのため
    のビデオ視聴者リクエストのスケジュール方法であっ
    て、前記ビデオ視聴者リクエストは同じ最大待ち許容時
    間を有し、 １の映画に対する複数の未処理パフォーマンス・リクエ
    ストのキューを保持するステップと、 前記複数の未処理パフォーマンス・リクエストのうちで
    最も長く待っているものの前記最大待ち許容時間が経過
    する直前に、前記１の映画についての共通ビデオ・スト
    リームで前記キューにある未処理パフォーマンス・リク
    エストにサービスするステップとを含む、ビデオ視聴者
    リクエストのスケジュール方法。
  4. 【請求項４】ビデオ・オン・デマンド・サービスのため
    の複数のビデオ視聴者リクエストのスケジュール方法で
    あって、前記複数のビデオ視聴者リクエストはそれぞれ
    異なり得る最大待ち許容時間を有し、 １の映画に対する複数の未処理パフォーマンス・リクエ
    ストのキューを保持するステップと、 前記複数の未処理パフォーマンス・リクエストのうちで
    最も早く前記最大待ち許容時間が経過するものの前記最
    大待ち許容時間が経過する直前に、前記１の映画につい
    ての共通ビデオ・ストリームで前記キューにある未処理
    パフォーマンス・リクエストにサービスするステップと
    を含む、ビデオ視聴者リクエストのスケジュール方法。
  5. 【請求項５】ビデオ・オン・デマンド・サービスに対す
    るビデオ視聴者リクエストのスケジュール方法であっ
    て、前記ビデオ視聴者リクエストは最大待ち許容時間を
    有し、 複数の映画のそれぞれに対する複数の未処理パフォーマ
    ンス・リクエストのキューを保持するステップと、 前記未処理パフォーマンス・リクエストのうちで最も長
    く待っているものを有するキュー上の未処理パフォーマ
    ンス・リクエストを、前記最大待ち許容限度時間が経過
    する直前にサービスするステップと、を含む、ビデオ視
    聴者リクエストのスケジュール方法。
  6. 【請求項６】前記キューは、第１のグループのキューと
    第２のグループのキューを含み、前記第１のグループの
    キューは頻繁にリクエストされる映画について保持さ
    れ、かつ前記第２のグループのキューはより頻度の低い
    サービスの映画について保持され、前記第１のグループ
    の各キューにおける全ての未処理パフォーマンス・リク
    エストが前記最大待ち許容時間が経過する前にサービス
    可能となるまで、前記第２のグループのキューがサービ
    スされない、請求項５に記載のビデオ視聴者リクエスト
    のスケジュール方法。
  7. 【請求項７】映画に対する未処理パフォーマンス・リク
    エストが最大待ち許容時間を有するビデオ・オン・デマ
    ンド・システムで用いるスケジュール装置であって、 １の映画に対する複数の未処理パフォーマンス・リクエ
    ストを保持するキュー手段と、 前記複数の未処理パフォーマンス・リクエストのうちの
    最も長く待っているものの待ち時間を判断する手段と、 前記複数の未処理パフォーマンス・リクエストのうちの
    最も長く待っているものの前記最大待ち許容限度時間を
    経過する直前に、前記キューにある全ての未処理パフォ
    ーマンス・リクエストをサービスする手段とを含む、ス
    ケジュール装置。
  8. 【請求項８】前記キュー手段は、頻繁にリクエストされ
    る映画についての第１のグループのキュー、及びより頻
    度の低いサービスの映画についての第２のグループのキ
    ューを保持する手段を含み、前記サービスする手段は、
    前記第１のグループの各キューにおける全ての未処理パ
    フォーマンス・リクエストが前記最大待ち許容時間が経
    過する前にサービス可能となるまで、前記第２のグルー
    プのキューにサービスしない、請求項７に記載のスケジ
    ュール装置。
JP14713895A 1994-08-08 1995-06-14 ビデオ視聴者リクェストのスケジュール方法及びスケジューラ Expired - Lifetime JP3360971B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/287,434 US5561456A (en) 1994-08-08 1994-08-08 Return based scheduling to support video-on-demand applications
US287434 1994-08-08

Publications (2)

Publication Number Publication Date
JPH0870446A JPH0870446A (ja) 1996-03-12
JP3360971B2 true JP3360971B2 (ja) 2003-01-07

Family

ID=23102889

Family Applications (1)

Application Number Title Priority Date Filing Date
JP14713895A Expired - Lifetime JP3360971B2 (ja) 1994-08-08 1995-06-14 ビデオ視聴者リクェストのスケジュール方法及びスケジューラ

Country Status (4)

Country Link
US (1) US5561456A (ja)
EP (1) EP0696872B1 (ja)
JP (1) JP3360971B2 (ja)
DE (1) DE69522768T2 (ja)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5828902A (en) * 1994-06-10 1998-10-27 Matsushita Electric Ind. Disc control device having reduced seek time by scheduling disc read requests
US7349976B1 (en) 1994-11-30 2008-03-25 Realnetworks, Inc. Audio-on-demand communication system
US5793980A (en) 1994-11-30 1998-08-11 Realnetworks, Inc. Audio-on-demand communication system
US5642152A (en) * 1994-12-06 1997-06-24 Microsoft Corporation Method and system for scheduling the transfer of data sequences utilizing an anti-clustering scheduling algorithm
JP2833507B2 (ja) * 1995-01-31 1998-12-09 日本電気株式会社 サーバ装置のデータアクセス制御方式
JP3575862B2 (ja) * 1995-03-16 2004-10-13 株式会社東芝 ストリームスケジューリング方法及び装置
US5940738A (en) 1995-05-26 1999-08-17 Hyundai Electronics America, Inc. Video pedestal network
US5793410A (en) 1995-05-26 1998-08-11 Hyundai Electronics America Video pedestal network
US5724646A (en) * 1995-06-15 1998-03-03 International Business Machines Corporation Fixed video-on-demand
JPH0955843A (ja) * 1995-08-10 1997-02-25 Nec Corp 画像データ送受信システム
US5768681A (en) * 1995-08-22 1998-06-16 International Business Machines Corporation Channel conservation for anticipated load surge in video servers
US5991811A (en) * 1995-09-04 1999-11-23 Kabushiki Kaisha Toshiba Information transmission system utilizing both real-time data transmitted in a normal-in-time direction and in a retrospective-in-time direction
EP1457896A3 (en) * 1995-10-26 2005-04-20 Matsushita Electric Industrial Co., Ltd. File system
US5926204A (en) * 1995-12-29 1999-07-20 At&T Corp Demand-adaptive system and method for telephone requested cable programming
US5631694A (en) * 1996-02-01 1997-05-20 Ibm Corporation Maximum factor selection policy for batching VOD requests
JPH09284748A (ja) * 1996-04-19 1997-10-31 Sony Corp 双方向情報伝送システムおよび双方向情報伝送方法
JP3175620B2 (ja) * 1996-06-21 2001-06-11 セイコーエプソン株式会社 印刷装置
WO1998004975A2 (en) * 1996-07-30 1998-02-05 Philips Electronics N.V. Bandwidth regulation system for multichannel memory arrays
US6263411B1 (en) * 1996-09-20 2001-07-17 Matsushita Electric Industrial Co., Ltd. Video server scheduling for simultaneous read-write requests
US5935206A (en) * 1996-12-13 1999-08-10 International Business Machines Corporation Automatic replication of digital video as needed for video-on-demand
FR2758040A1 (fr) * 1996-12-27 1998-07-03 Thomson Multimedia Sa Procede de controle du flux de communication dans un reseau interactif
JP3810530B2 (ja) * 1997-09-18 2006-08-16 富士通株式会社 ビデオサーバシステム、コンテンツ動的配置装置及びコンテンツ動的配置方法
US6023720A (en) * 1998-02-09 2000-02-08 Matsushita Electric Industrial Co., Ltd. Simultaneous processing of read and write requests using optimized storage partitions for read and write request deadlines
DE19807076A1 (de) 1998-02-20 1999-08-26 Cit Alcatel Datenbereitstellungsystem
US6170042B1 (en) * 1998-02-24 2001-01-02 Seagate Technology Llc Disc drive data storage system and method for dynamically scheduling queued commands
JPH11341471A (ja) 1998-05-28 1999-12-10 Hitachi Ltd 映像配信装置および映像配信システム
KR100285590B1 (ko) * 1998-05-29 2001-04-02 전주범 브이오디(vod)서버시스템에서의서비스제어방법
DE19831516A1 (de) * 1998-07-14 2000-01-20 Alcatel Sa Verfahren zum Betrieb eines Servers sowie Server und Steuereinheit
US6378036B2 (en) * 1999-03-12 2002-04-23 Diva Systems Corporation Queuing architecture including a plurality of queues and associated method for scheduling disk access requests for video content
US6691208B2 (en) 1999-03-12 2004-02-10 Diva Systems Corp. Queuing architecture including a plurality of queues and associated method for controlling admission for disk access requests for video content
US6876994B2 (en) * 2000-05-30 2005-04-05 Matsushita Electric Industrial Co., Ltd. Data acquisition apparatus and method
US7107606B2 (en) * 2000-08-30 2006-09-12 The Chinese University Of Hong Kong System and method for highly scalable video on demand
JP3646983B2 (ja) * 2000-10-19 2005-05-11 株式会社ソニー・コンピュータエンタテインメント 待ち順番表示方法、待ち順番表示方法のプログラム、待ち順番表示方法のプログラムが記録された記録媒体、及びコンテンツ配信システム
EP2986017B1 (en) * 2001-05-24 2017-11-22 ViXS Systems Inc. Method and apparatus for managing resources and multiplexing a plurality of channels in a multimedia stream
US8291457B2 (en) 2001-05-24 2012-10-16 Vixs Systems, Inc. Channel selection in a multimedia system
US7617515B1 (en) * 2001-05-24 2009-11-10 Vixs Systems, Inc. Method and apparatus for managing resources in a multimedia system
US20090031419A1 (en) 2001-05-24 2009-01-29 Indra Laksono Multimedia system and server and methods for use therewith
US20030005455A1 (en) * 2001-06-29 2003-01-02 Bowers J. Rob Aggregation of streaming media to improve network performance
US7065764B1 (en) * 2001-07-20 2006-06-20 Netrendered, Inc. Dynamically allocated cluster system
FR2855706A1 (fr) * 2003-05-26 2004-12-03 France Telecom Procede de chargement d'un contenu multimedia distant mettant en oeuvre une temporisation, terminal multimedia et serveur correspondants
US20050138664A1 (en) * 2003-12-23 2005-06-23 Raja Neogi System and method for allocating resources in an adaptive media center processing system
JP5479107B2 (ja) * 2007-01-11 2014-04-23 トムソン ライセンシング コンテンツ通信のためのシステム及び方法
US20080196055A1 (en) * 2007-02-09 2008-08-14 Cable Television Laboratories, Inc. Restricting access to content
US7986705B2 (en) * 2007-06-13 2011-07-26 International Business Machines Corporation Determining a transmission order for frames based on bit reversals of sequence numbers
US20080310309A1 (en) * 2007-06-13 2008-12-18 Glenn Darrell Batalden Sending content from multiple queues to clients
US7890651B2 (en) * 2007-06-13 2011-02-15 International Business Machines Corporation Sending content from multiple content servers to clients at time reference points
US8554941B2 (en) * 2007-08-30 2013-10-08 At&T Intellectual Property I, Lp Systems and methods for distributing video on demand
US7797391B2 (en) * 2007-09-19 2010-09-14 The Chinese University Of Hong Kong Load balancing and admission scheduling in pull-based parallel video servers
US9191686B2 (en) 2011-07-22 2015-11-17 Honeywell International Inc. System and method of implementing synchronized audio and video streaming
US9516078B2 (en) 2012-10-26 2016-12-06 Cisco Technology, Inc. System and method for providing intelligent chunk duration
US20140281000A1 (en) * 2013-03-14 2014-09-18 Cisco Technology, Inc. Scheduler based network virtual player for adaptive bit rate video playback
WO2016099364A1 (en) * 2014-12-19 2016-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Managing content streaming requests
US10613998B2 (en) * 2018-07-30 2020-04-07 EMC IP Holding Company LLC Multi-level time decay storage queue
US20230409239A1 (en) * 2022-06-21 2023-12-21 Micron Technology, Inc. Efficient command fetching in a memory sub-system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4949187A (en) * 1988-12-16 1990-08-14 Cohen Jason M Video communications system having a remotely controlled central source of video and audio data
ATE154182T1 (de) * 1989-08-23 1997-06-15 Delta Beta Pty Ltd Optimisierung einer programmübertragung
US5421031A (en) * 1989-08-23 1995-05-30 Delta Beta Pty. Ltd. Program transmission optimisation
US5247347A (en) * 1991-09-27 1993-09-21 Bell Atlantic Network Services, Inc. Pstn architecture for video-on-demand services
US5508732A (en) * 1993-03-22 1996-04-16 International Business Machines Corporation Data server, control server and gateway architecture system and method for broadcasting digital video on demand
US5414455A (en) * 1993-07-07 1995-05-09 Digital Equipment Corporation Segmented video on demand system
US5453779A (en) * 1994-03-15 1995-09-26 International Business Machines Corporation Scheduling policies with grouping for providing VCR control functions in a video server
US5461415A (en) * 1994-03-15 1995-10-24 International Business Machines Corporation Look-ahead scheduling to support video-on-demand applications
US5477263A (en) * 1994-05-26 1995-12-19 Bell Atlantic Network Services, Inc. Method and apparatus for video on demand with fast forward, reverse and channel pause

Also Published As

Publication number Publication date
JPH0870446A (ja) 1996-03-12
DE69522768T2 (de) 2002-07-04
EP0696872A3 (en) 1997-01-29
EP0696872B1 (en) 2001-09-19
US5561456A (en) 1996-10-01
DE69522768D1 (de) 2001-10-25
EP0696872A2 (en) 1996-02-14

Similar Documents

Publication Publication Date Title
JP3360971B2 (ja) ビデオ視聴者リクェストのスケジュール方法及びスケジューラ
JP2742390B2 (ja) ビデオ・システムにおけるポーズ・レジュームをサポートする方法およびシステム
JP3349055B2 (ja) ビデオ・リクエストのスケジュール化方法及び装置
JP3202922B2 (ja) ビデオ・サーバにおいてビデオのチャネルへの配信をスケジュールする方法およびビデオオンデマンド・システム
KR0152485B1 (ko) 중지-재개 지원 방법
US6032200A (en) Process scheduling for streaming data through scheduling of disk jobs and network jobs and the relationship of the scheduling between these types of jobs
Dan et al. Dynamic batching policies for an on-demand video server
US6041354A (en) Dynamic hierarchical network resource scheduling for continuous media
US5544327A (en) Load balancing in video-on-demand servers by allocating buffer to streams with successively larger buffer requirements until the buffer requirements of a stream can not be satisfied
US5808607A (en) Multi-node media server that provides video to a plurality of terminals from a single buffer when video requests are close in time
Dan et al. Channel allocation under batching and VCR control in video-on-demand systems
JP3326131B2 (ja) スケジューリングシステム及びその方法
WO1995012947A1 (en) Scheduling and admission control policy for a continuous media server
Lau et al. A novel video-on-demand storage architecture for supporting constant frame rate with variable bit rate retrieval
CHIUEH et al. Design and implementation of the stony brook video server
Chiueh et al. Design and implementation of the stony brook video server
Lee et al. Design and performance evaluation of a multimedia web server

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20071018

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081018

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081018

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091018

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091018

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101018

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101018

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111018

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121018

Year of fee payment: 10

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121018

Year of fee payment: 10

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131018

Year of fee payment: 11

EXPY Cancellation because of completion of term