JPH10257490A - 適応アニメーション圧縮用システム - Google Patents

Abstract

(57)【要約】 【課題】 異なる圧縮アルゴリズムを用いて各フレーム
を圧縮することのできるデジタル映画システムを提供す
る。 【解決手段】 マルチメディアアニメーションにおける
データのフレームを処理するのに使用される圧縮−圧縮
解除方法を開示する。この方法は、所定の基準を設定
し、データに関連したスプライトベースのフレームを形
成し、上記データと手前のフレームとのピクセルごとの
比較を実行して、フレームの差をベースとするフレーム
を形成する段階を含む。更に、上記スプライトベースの
フレームの第１データレートと、上記フレームの差をベ
ースとするフレームの第２データレートを決定し、上記
第１及び第２のデータレートを上記所定の基準と比較
し、そして上記スプライトベースのフレーム及び上記フ
レームの差をベースとするフレームの一方を圧縮された
フレームとして選択するという段階を含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチメディアシ
ステムに係り、より詳細には、フレームの差をベースと
するシステム又はスプライトをベースとするシステムを
所定の基準に基づいて選択することのできるシステムに
係る。

【０００２】

【従来の技術】コンピュータが最初に開発されたときに
は、非常に高価であった。その結果、それらを購入でき
るのは、大きな調査研究所や会社だけであった。従っ
て、コンピュータは、主として、科学的な問題を解決し
たり（例えば、流体の振る舞いを模擬する）、大きな会
社の事業運営を支援したりする（例えば、保険会社の会
計及び顧客記録を処理する）のに使用された。これらの
目的で設計されたソフトウェアプログラムは、番号及び
テキストを用いてユーザと通信する。これらソフトウェ
アプログラムのユーザは、技術的に訓練され、このよう
な環境において快適であった。従って、これらのプログ
ラムが情報をグラフィックやイメージの形態で与える必
要性はほとんどなかった。

【０００３】過去数年間に、コンピュータの価格は急激
に低下した。今や、コンピュータは多くの家庭や小さな
会社で購入されている。これらコンピュータのユーザ
は、グラフィック、テキスト、イメージ、アニメーショ
ン、サウンド等の組合せを含むマルチメディア環境の取
り扱いを快適に行っている。その結果、種々のマルチメ
ディアハードウェア及びソフトウェアコンポーネント
（サウンドカード、ビデオカード、ＣＤＲＯＭリーダ
ー、ゲームソフト、教育ソフト、等）が急速に開発され
た。現在、市場に出回る多数のコンピュータは、ＣＤＲ
ＯＭリーダー、高品質のサウンドカード、並びに高解像
度のビデオカード及びモニタと共に販売されている。こ
れらのコンピュータは、「マルチメディアコンピュー
タ」と称されることもある。

【０００４】次第の多数のこれらマルチメディアコンピ
ュータに、コンピュータをインターネットのようなネッ
トワークに接続するネットワークアクセスデバイス（例
えばモデム）が装備されるようになった。インターネッ
トにおける重要なプロトコルは、ワールドワイドウェブ
（ウェブ）である。これは、大きな文書領域への普遍的
なアクセスを与えることを目的とするワイドエリアハイ
パーメディア情報検索システムである。文書は、グラフ
ィック、テキスト、音声又は映像ファイル（又はそれに
対するリンク）を含むことができる。従って、インター
ネットにわたり非常に多数のマルチメディアデータを搬
送することが必要となる。

【０００５】マルチメディアソフトウェアアプリケーシ
ョンデータの１つの特徴は、それらのデータがキャラク
タベースのデータよりも相当に大きいことである。例え
ば、３２ビットカラーの単一の４８０ｘ６４０ピクセル
の像は、約１．２メガバイト（Ｍバイト）のサイズを有
する。１０秒巾の音声の断片は、０．５Ｍバイトの記憶
量を必要とする。これに対して、ＡＳＣＩＩテキストと
して記憶される１ページの文書は、数キロバイト（Ｋバ
イト）しか必要としない。

【０００６】１つの形式のマルチメディアソフトウェア
アプリケーションは、デジタル映画を含み、その一例が
アニメーションである。アニメーションは、一連のフレ
ームで形成される。各フレームは、層形状で作られる。
ある意味の連続性を形成するために、アプリケーション
は、典型的に、毎秒所定数のフレーム（例えば、毎秒３
０フレーム）を表示する。上記のように、各フレームの
サイズは、約１．２Ｍバイトのデータである。従って、
数分のアニメーションに数百Ｍバイトのデータが必要と
なる。

【０００７】マルチメディアデータのサイズを減少する
ための１つの方法は、圧縮及び圧縮解除（コーデック）
ソフトウェアツールを使用することである。マルチメデ
ィアデータは、先ず、圧縮装置により小さなサイズに圧
縮される。圧縮されたデータは、次いで、記憶装置（例
えば、ローカルエリアネットワーク又インターネットに
使用されるＣＤＲＯＭ又はネットワークサーバ）に記憶
されそして顧客へ分配される。顧客がアプリケーション
の再生を希望するときには、圧縮されたデータが記憶媒
体から検索されそしてランダムアクセスメモリ（ＲＡ
Ｍ）へロードされる。このデータは、次いで、顧客のコ
ンピュータにより圧縮解除されそして再生される。

【０００８】

【発明が解決しようとする課題】２つの重要な形式のコ
ーデックは、スプライトをベースとするコーデックと、
フレームの差をベースとするコーデックである。典型的
なスプライトをベースとするコーデックにおいては、一
般的に使用される像（例えば、アニメーションの「キャ
ストメンバー（配役）」）がＲＡＭに記憶される。モニ
タ上のある位置にキャストメンバーを描くために、アプ
リケーションは、そのキャストメンバーの識別番号と所
望の座標をコーデックに供給するだけでよい。このフレ
ームにキャストメンバーを表示するのに必要な全データ
量は、キャストメンバーの像を描くのに必要な数Ｋバイ
トのデータではなく、数バイトに過ぎない。従って、あ
る形式のフレームに対して非常に高い圧縮比を得ること
ができる。その結果、圧縮されたデータのサイズは小さ
く、従って、記憶媒体からＲＡＭへ転送する必要のある
データの量も少ない。従って、必要なデータレートが低
くなる。従って、このコーデックは、データレートに関
しては非常に効率的である。しかしながら、フレーム当
たりに描く必要のあるピクセルの量は多くなる。という
のは、フレームに現れる全てのキャストメンバーを描き
直す必要があるからである。その結果、非常に多数のピ
クセルを描くことが必要となる（即ち、ピクセルレート
が高くなる）。従って、このコーデックは、ピクセルレ
ートに関しては効率が悪い。

【０００９】フレームの差をベースとするコーデックに
おいては、次々のフレーム間で変化するピクセル（即
ち、２つのフレーム間の相違）のみが記憶される。圧縮
解除の間に、コンピュータモニタに差を描くことにより
新たなフレームが描かれる。典型的に、フレームの差を
ベースとするコーデックの圧縮比は、スプライトをベー
スとするコーデックほど高くない。従って、これは、デ
ータレートに関して効率的でない。しかしながら、像の
見掛けに僅かな変化しかない（例えば、キャストメンバ
ーの口しか変化しない）場合には、全像（例えば、スプ
ライトをベースとするコーデックにおけるキャストメン
バー）を描き直す必要がない。従って、ピクセルレート
に関しては非常に効率的である。

【００１０】上記の例は、種々のコーデックが異なる特
性を有することを示している。公知のマルチメディアア
プリケーションは、デジタル映画の全てのフレームに同
じコーデックを使用している。しかしながら、映画の全
てのフレームに対して最適な結果を生じることのできる
コーデックをもつことは困難である。

【００１１】

【課題を解決するための手段】本発明は、異なる圧縮ア
ルゴリズムを用いて各フレームを圧縮することのできる
デジタル映画システム（アニメーション及びデジタルビ
デオのような）を提供する。異なる圧縮アルゴリズム
は、異なる利点と欠点を有することが明らかである。従
って、各フレームごとに適当な圧縮アルゴリズムを仕立
てることにより、マルチメディアシステムの性能を著し
く改善することができる。

【００１２】本発明の１つの実施形態においては、デー
タサイズ及び／又は描かれるべきピクセルの数を用い
て、使用する圧縮が選択される。データサイズは、記憶
媒体からシステムＲＡＭにデータを転送するのに必要な
時間の長さに影響する。描かれるべきピクセルの数（即
ち、ピクセルレート）は、コンピュータのスクリーン上
にフレームを配するのに必要なＣＰＵサイクルの数に作
用する。ある圧縮アルゴリズムは、小さなデータサイズ
を有する圧縮データを発生するが、ピクセルレートが高
くなる。これは、例えば、スプライトをベースとする圧
縮アルゴリズムである。他の圧縮アルゴリズムは、小さ
なピクセルレートを有する圧縮データを発生するが、デ
ータサイズが大きくなる。これは、例えば、フレームの
差をベースとする圧縮アルゴリズムである。各フレーム
ごとに適当な圧縮アルゴリズムを使用することにより、
マルチメディアシステムの性能を改善することができ
る。

【００１３】本発明の実施形態においては、デジタル映
画の各フレームは、スプライトをベースとする圧縮アル
ゴリズムを用いて圧縮され、次いで、フレームの差をベ
ースとする圧縮アルゴリズムを用いて圧縮される。これ
らの圧縮アルゴリズムの結果が予め定められた基準と比
較される。この基準に最良に合致するアルゴリズムから
の圧縮フレームがこのフレームに対して選択される。他
方の圧縮フレームは、破棄される。従って、圧縮された
映画は、異なる圧縮アルゴリズムを用いて圧縮されたフ
レームで構成される。圧縮解除の間に、各圧縮フレーム
は、適当な圧縮解除アルゴリズムを用いて圧縮解除され
る。

【００１４】

【発明の実施の形態】本発明のこれら及び他の特徴は、
添付図面を参照した本発明の以下の詳細な説明より明ら
かとなろう。本発明は、新規なマルチメディア圧縮及び
圧縮解除システム並びにそれに関連した方法に係る。以
下の説明は、当業者が本発明を実施しそして利用できる
ようにするためのものである。特定の用途についてのみ
一例として説明する。当業者であれば、好ましい実施形
態に対する種々の変更が容易に明らかとなろうし、ここ
に述べる一般的な原理を本発明の精神及び範囲から逸脱
せずに他の実施形態や用途に適用することができよう。
従って、本発明は、ここに示す実施形態に限定されるも
のではなく、ここに述べる原理及び特徴に一致する最も
広い範囲に基づくものとする。

【００１５】本発明を理解するために、公知のスプライ
トをベースとするコーデック及びフレームの差をベース
とするコーデックについて説明する。アニメーション
は、層（レイヤ）形状から形成された一連のフレームで
作られる。スプライトをベースとする圧縮においては、
「スプライト」の集合体の像が準備されて記憶される。
これらのスプライトには、識別情報が指定される。スプ
ライトがレイヤに現れる場合には、スプライトの識別及
びレイヤにおけるその位置を与えるだけで充分である。
選択されたスプライトの全像を与える必要はない。その
結果、スプライトを記述するのに数バイトだけで充分で
ある（像を与えるのにもし必要であれば、１Ｋバイト以
上が必要となるが）。スプライトを表示することが必要
なときは、像が記憶装置から検索され、そしてモニタ上
の予め指定された位置にペイントされる。

【００１６】レイヤをペイントする際には、スプライト
を一度に１つづつペイントしなければならない。スプラ
イトが手前のフレームに存在する場合には、予め存在す
るスプライトを消去し（それらの上に背景カラーをペイ
ントすることにより）そして新たなスプライトをペイン
トすることが必要である。これらのペインティングがモ
ニタのスクリーン上に直接実行されるときには、ピクセ
ルのカラーがストロボ照明と同様に１つのカラーから別
のカラーへと繰り返し変化するので、著しいフリッカが
発生する。従って、スプライトをベースとする圧縮シス
テムでは、各フレームに対する像が最初にオフスクリー
ンバッファに描かれ、次いで、モニタのスクリーンへコ
ピーされる。

【００１７】要約すれば、スプライトベースのコーデッ
クは、各フレームを再組み立てするのに少なくとも３つ
の段階を必要とする。 １）差を消去する：即ち、再組み立てされるフレームが
手前のフレームと異なる場合にはオフスクリーンバッフ
ァの領域を消去する（例えば、背景カラーに対してペイ
ントする）。 ２）スプライトを描く：即ち、オフスクリーンバッファ
に新たなスプライトを描く。 ３）スクリーンへ転送する：即ち、オフスクリーンバッ
ファの内容をスクリーンへコピーする。

【００１８】各スプライトを描くために３段階プロセス
を使用する必要があるために、描写専用のコンピュータ
リソースの量が大きなものとなる。スプライトをベース
とするコーデックの利点は、スプライトがしばしば再使
用されるアニメーションに対して良好に機能することで
ある。これらのアニメーションにおいては、スプライト
が外部の記憶装置（例えば、ＣＤＲＯＭ又はネットワー
クサーバ）からＲＡＭへ一度にロードされ、そして記憶
媒体から再びロードする必要なく繰り返し使用すること
ができる。

【００１９】フレームの差をベースとするコーデック
は、圧縮解除において１つの段階のみを必要とし、即ち
フレーム間の相違をスクリーンに描く。この段階は、直
接スクリーンに描くことにより実行することができ、即
ちオフスクリーンバッファに描く必要はない。フリッカ
は、ここでは、問題とならない。というのは、作用を受
けるピクセルのカラーが１つのフレームから別のフレー
ムへ一度変化するだけだからである。従って、データを
圧縮解除して描写するのに、コンピュータリソース（例
えば、ＣＰＵサイクル及び一時的なバッファスペース）
は、ほとんど必要とされない。

【００２０】フレームの差をベースとする方法が図１な
いし３に例示されている。図１は、スクリーン４０２に
表示されたウインドウ４０４を示す。ウインドウ４０４
は、背景パターン４０８にペイントされた内実のパター
ンを有する長方形状４０６を含む。図２は、異なる位置
にペイントされた形状４１２を有するウインドウ４１０
を示す。ウインドウ４１０は、ウインドウ４０４と同じ
サイズ及び形状を有することができ、そして形状４１２
は、形状４０６と同じサイズ及び形状を有することがで
きる。図１のウインドウ４０４を図２のウインドウ４１
０へと変更する１つの方法は、背景パターンを有する長
方形状４１６と、内実のパターンを有する別の長方形状
４１８とを備えたウインドウ４１４を形成することであ
る（図３参照）。形状４１６及び４１８のサイズ及び形
状は、各々、形状４０６及び４１２と同じである。ウイ
ンドウ４１４がウインドウ４０４の上にペイントされた
ときには、ウインドウ４１０と同じ結果が得られる。ウ
インドウ４１４のペインティングは、カラーの変化が繰
り返されないのでフリッカを生じることはない。その結
果、オフスクリーンバッファを使用する必要がない。ウ
インドウ４１４を形成する１つの方法は、ウインドウ４
０４と、更に描写されるべきウインドウ４１０とのピク
セルごとの比較を実行することである。この方法は、当
業者に良く知られている。

【００２１】又、フレームの差をベースとするコーデッ
クは、オフスクリーンバッファが使用される状態にも使
用できる。オフスクリーンバッファが必要とされる場合
のスプライトベースの圧縮に勝るピクセルレートの改善
は、直接的なスクリーン描写が可能である場合ほど大き
くない。しかしながら、フレームの差をベースとするコ
ーデックは、ピクセルレートに関しては、スプライトベ
ースのコーデックよりも更に効率的である。というの
は、全てのスプライトを完全に再描写する必要がないか
らである。

【００２２】フレームの差をベースとするコーデック
は、一般に、大きなデータサイズを有する。例えば、背
景が静止している間に同じ形状が１つのフレームから別
のフレームへ１ピクセル移動される場合を考える。この
場合、移動形状のサイズが大きいと、１つのフレームか
ら別のフレームへ多数のピクセルが影響を受ける。影響
を受けるピクセルのデータを、記憶媒体からＲＡＭへロ
ードすることが必要となる。その結果、データ転送のた
めの帯域巾要求が高くなる。一方、スプライトベースの
圧縮は、新たな座標を形状に指定することを伴う（これ
は、数バイトのデータしか必要としない）。

【００２３】フレームの差をベースとする方法の別の欠
点は、差のフレームが手前のフレームに既に含まれてい
る情報に依存しそしてそれを使用することである。しか
しながら、手前のフレームに依存しない「キーフ」レー
ムのようなフレームもある。その結果、キーフレーム
は、フレームの差をベースとする圧縮が使用される場合
には、データレートに関して非常に大きくなる（即ち、
多量のデータをＲＡＭにロードする必要がある）と共
に、ピクセルレートに関しても非常に大きなものとなる
（即ち、多数のピクセルをスクリーンに描くことが必要
となる）。この状態を取り扱うために、アップルコンピ
ュータのクイックタイムのようなあるデジタル映画（ム
ービー）システムは、グラフィックスを音声と同期状態
に保つためにフレームをスキップ又はドロップさせる。
その結果、アニメーションは、ぎこちない動きになる。

【００２４】本発明の１つの特徴は、各フレームに対す
る最良の圧縮アルゴリズムをフレームごとのベースで選
択できるコーデックを開発することを含む。その結果、
これらアルゴリズムの欠点を回避しながらその利点が活
用される。本発明では、各フレームは、スプライトをベ
ースとする圧縮アルゴリズムと、フレームの差をベース
とする圧縮アルゴリズムの両方を使用して圧縮される。
これら２つの結果が、所定の基準と比較される。選択さ
れたフレームは、比較の結果に基づき、スプライトベー
スのアルゴリズム又はフレームの差をベースとする圧縮
アルゴリズムのいずれかを用いて圧縮されたフレームで
ある。従って、改良された性能を得ることができる。

【００２５】本発明の１つの実施形態においては、デー
タのサイズ及び／又は描写されるべきピクセルの数は、
圧縮アルゴリズムを選択するのに使用される。データサ
イズのみを使用する例は、フレームの差のコーデックを
用いて圧縮されたフレームが描写段階が少ないために常
により速く描かれるという観察に基づく。従って、スプ
ライトベースの圧縮のデータサイズが、フレームの差を
ベースとする圧縮のデータサイズと同じであるか又はそ
れより小さい場合には、フレームの差をベースとする圧
縮が最適な圧縮形式となる。従って、２つの圧縮形式間
の選択は、データサイズのみに基づく。あるときには、
データレートが問題にならない。このような場合には、
データサイズは、決定ファクタとならない。例えば、フ
レームの差をベースとする圧縮を用いると、スプライト
ベースの圧縮を使用するよりも、１０％多くのデータを
生じるが、描写時間が５０％少ない場合には、たとえデ
ータサイズが大きくても、描写時間が短縮されるため
に、フレームの差をベースとする圧縮が選択される。こ
の場合に、データレート及びピクセルレートの比は、最
適な圧縮形式を選択するのに使用される。更に、この比
は、ユーザが選択できるのが好ましい。というのは、異
なるデータ供給システム（例えば、ＣＤＲＯＭ又はイン
ターネット）は、異なる帯域巾を有するからである。

【００２６】図４は、本発明の圧縮動作を示すフローチ
ャート３００である。ステップ３０４において、圧縮形
式を選択するための所定の基準が入力される（例えば、
ソフトウェアデベローパにより）。フレームを検討し
て、それがキーフレームであるかどうか判断する（ステ
ップ３０６）。キーフレームである場合には、スプライ
トベースのアルゴリズムが使用される（ステップ３０
８）。フローチャート３００は、次いで、ステップ３０
６へ戻り、次のフレームを検査する。フレームがキーフ
レームでない場合には、フレームは、スプライトベース
のアルゴリズムを用いて圧縮され（ステップ３１０）、
次いで、フレームの差をベースとするアルゴリズムを用
いて圧縮される（ステップ３１２）。ステップ３１２で
は、ピクセルごとの比較が行われるのが好ましい。ステ
ップ３１０及び３１２を実行する順序は重要ではないこ
とに注意されたい。ステップ３１４においては、これら
２つのアルゴリズムを用いる圧縮の当該パラメータが決
定される（例えば、データサイズ及びピクセルレー
ト）。ステップ３１６では、パラメータが所定の基準と
比較される。ステップ３１８では、２つの圧縮されたフ
レームの一方がステップ３１６の比較に基づいて選択さ
れる。選択されたフレームは、このフレームのデータを
表し、記憶媒体に記憶される。他方の圧縮されたデータ
は、破棄される。データのあるフィールドは、選択され
た圧縮形式を指示するために指定される。フローチャー
ト３００は、次いで、ステップ３０６へ戻って、次のフ
レームを検査する。

【００２７】圧縮解除の際に、各フレームの上記フィー
ルドが検査されて、その圧縮形式が決定される。次い
で、フレームは、それに応じて圧縮解除される。本発明
の１つの特徴は、ステップ３１２で実行されるピクセル
ごとの比較が、スプライトベースのアルゴリズムの圧縮
解除時間を短縮するのに使用できることである。これが
図５及び６に示されている。図５は、僅かに重畳する２
つのスプライト４４２及び４４４を示している。図６
は、同じスプライトを示すが、スプライト４４２がスプ
ライト４４４の大部分に重畳してそれを隠している。ス
プライト４４４の僅かな部分（破線のボックス４４６で
囲まれて示された）のみがスクリーン上に見える。従来
のスプライトベースの方法が使用される場合には、スプ
ライト４４２及び４４４の全像を、一度に１つづつ、オ
フスクリーンバッファにペイントする必要がある。しか
しながら、ピクセルごとの比較を実行すると、図６のス
クリーンを示すためにスプライト４４４の僅かな部分だ
けをペイントすればよいことが容易に明らかである。従
って、ボックス４４６の部分が完了したときにスプライ
ト４４４のペイント動作を停止することができる。その
結果、コンピュータリソースを大幅に節約することがで
きる。ボックス４４６に関連した情報は、従来の仕方で
圧縮解除装置に送ることができる（例えば、どんな種類
のデータのかたまりが続くかを知らせる標準化されたヘ
ッダを有する可変長さ構造体であるフレームデータサン
プルにおいて）。

【００２８】又、ピクセルごとの比較は、データ及びピ
クセルレートを減少するように新たなスプライトを形成
するのに使用することもできる。図５及び６に戻ると、
フレームは、スプライト４４２及び４４４の前方を飛ぶ
航空機も含むと仮定する。この航空機は、独立したスプ
ライトとして記録され、そして個別のレイヤにペイント
される。この実施形態では、ピクセルごとの比較の結果
を用いてスプライト４４２及び４４４の新たな複合スプ
ライトを形成することができる。圧縮解除においては、
この新たな複合スプライトを１つのレイヤとしてペイン
トすることができる。従って、航空機は、個別のレイヤ
としてペイントすることができる。その結果、システム
の性能が改善される。

【００２９】図７は、本発明を実施するのに使用できる
コンピュータシステム１００のブロック図である。コン
ピュータシステム１００は、ＣＰＵ１０４と、リードオ
ンリメモリ（ＲＯＭ）１０６と、ＲＡＭ１０８と、モニ
タ１１０と、ＣＤＲＯＭリーダー１１２と、ハードディ
スク１１４と、ユーザがデータを入力できるようにする
装置、例えば、キーボード１１８及びマウス１２０とを
備えている。ケース１１６は、ＣＰＵ１０４、ＲＯＭ１
０６、ＲＡＭ１０８及びハードディスク１１４を収容す
るのに使用される。動作に際し、ユーザは、本発明を組
み込んだソフトウェア及びデータを含むＣＤＲＯＭ（図
示せず）をＣＤＲＯＭリーダー１１２へ挿入する。キー
ボード１１８又はマウス１２０は、コンピュータシステ
ム１０がＣＤＲＯＭに関連した所望のアプリケーション
を実行するために使用される。リーダー１１２は、ＣＤ
ＲＯＭに含まれたデータを、ＣＰＵ１０４により実行す
るためにＲＡＭ１０８へ転送する。

【００３０】本発明を例示するために、特定のコンピュ
ータシステム、例えば、アップルマッキントッシュをベ
ースとするコンピュータがコンピュータシステム１００
として使用される。マッキントッシュコンピュータは、
ＲＯＭ１０６及びハードディスク１１４に記憶されたオ
ペレーティングシステムにより制御される。これは、マ
ルチメディアアプリケーションを開発するためにソフト
ウェアデベローパを助成する多数のソフトウェアツール
を含む。本発明の好ましい実施形態は、アプリケーショ
ンを開発する最も効率的な方法であることから、これら
のツールを使用する。インテルをベースとするコンピュ
ータにおいて実行されるマイクロソフトウインドウズの
ような他の種類のコンピュータシステムも、同様のツー
ルとなり得る。それらは、本発明を組み込んだ製品を開
発するのに使用できる。或いは、デベローパがそれ自身
のツールを開発してもよい。

【００３１】アプリケーションの一例は、アニメーショ
ンのアプリケーションである。このアプリケーション
は、映画データを開発及び上演するためのビヒクルとし
てアップルコンピュータインクにより開発された「クイ
ックタイム(Quick Time)」と称するソフトウェア製品を
使用する。クイックタイムは、クロスプラットホームス
トリーミング(cross-platform streaming)ビデオ技術で
ある。このアプリケーションにおいて、「ストリーミン
グ」という用語は、データが再生されるときにそれがロ
ードされることを意味する。コンピュータの性能を最適
化するために、クイックタイムは、それが再生されると
ころより前に小さなビットをロードする。

【００３２】ほとんどのマルチメディアアプリケーショ
ンは、アニメーション、ビデオ及びグラフィックデータ
のサイズを減少するためにコーデックを使用する。クイ
ックタイムは、多数の内蔵コーデックを含み、デベロー
パがそれら自身のコーデックを内蔵コーデックと置き換
えられるようにする。本発明は、クイックタイムの内蔵
コーデックに代わるコーデックとして実施することがで
きる。

【００３３】図８は、クイックタイムを用いた映画記録
及び再生システム１５０の回路図である。クイックタイ
ムの詳細は、両方とも「アップルテクニカルライブラリ
ー」のメンバーであってアジソン−ウェスリーパブリッ
シングカンパニーにより出版された「インサイドマッキ
ントッシュ：クイックタイム(Inside Macintosh: Quick
Time) 」及び「インサイドマッキントッシュ：クイック
タイムコンポーネント(Inside Macintosh: QuickTime C
omponents)」と題する２つの出版物に開示されている。
これら２つの文献は、参考としてここに取り上げるもの
である。

【００３４】クイックタイムでは、１組の時間ベースデ
ータを「ムービー」と称する。この１組のデータは、音
声又は映像に限定されるものではなく、財務データ、ラ
ボラトリーデータ又は他の時間従属データであってもよ
い。従って、クイックタイムムービーは、異なるソース
から到来する時間従属データの連続流である。この例で
は、このデータ流は、アニメーションのフレームより成
る。

【００３５】クイックタイムは、複数のコンポーネント
を含む。コンポーネントは、マッキントッシュコンピュ
ータシステムの「コンポーネントマネージャー」により
登録されたコードリソースである。各コンポーネント
は、定められた１組の特徴をサポートし、そしてそのク
ライエントのアプリケーションに特定のアプリケーショ
ンプログラムインターフェイス（ＡＰＩ）を与える。従
って、アプリケーションは、所与の技術を実施しそして
管理する細部から分離される。例えば、ソフトウェアデ
ベローパは、圧縮アルゴリズムを実施するためにいかに
コードを書き込むかを知る必要なく、圧縮コンポーネン
トを使用して圧縮を行うことができる。

【００３６】図８は、ムービーデータ（アニメーション
データ１５８のような）を受け入れる像圧縮マネージャ
ーの圧縮ファンクション１６４を示す。像圧縮マネージ
ャーは、像及び一連の像（例えば、アニメーション）を
圧縮及び圧縮解除するための共通のインターフェイスを
アプリケーションに与える。又、デベローパが特定の結
果に対して適当なツールを選択できるようにする多数の
圧縮及び圧縮解除オプションも与える。更に、クイック
タイムのコーデックがデベローパの要求を満たさない場
合にはデベローパが自分のコーデックを使用できるよう
にする。

【００３７】像圧縮マネージャーの圧縮ファンクション
１６４は、像圧縮コンポーネント１６８を呼び出すこと
により像を圧縮する。又、像圧縮マネージャーは、像圧
縮解除コンポーネント１９０を呼び出すことにより再生
中に像を圧縮解除することのできる圧縮解除ファンクシ
ョン１８８も含む。これら２つのコンポーネントは、像
圧縮マネージャーに標準インターフェイスを与えて各像
圧縮及び像圧縮解除サービスを果たすコードリソースで
ある。像圧縮コンポーネント１６８及び像圧縮解除コン
ポーネント１９０は、デベローパにより供給することも
できる。「コードネームスペック」と称する像圧縮マネ
ージャーデータ構造体は、デベローパによりそのコーデ
ックコンポーネントの名前を識別するのに使用できる。

【００３８】好ましい実施形態において、本発明のため
に特に設計されたコーデックコンポーネントが使用され
る。これらのコンポーネントは、アニメーションデータ
の各フレームを、そのフレームに対して最も適したアル
ゴリズムを使用して圧縮及び圧縮解除（圧縮コンポーネ
ントが使用されるか圧縮解除コンポーネントが使用され
るかに基づいて）するように設計される。圧縮コンポー
ネントを実施するためのフローチャートが図４に示され
ている。圧縮解除装置の実施形態も上記で説明した。図
８は、本発明のアルゴリズムを実施するためのコードリ
ソースを含んだ新規な圧縮装置１６９及び新規な圧縮解
除装置１９１を示す。上記したように、データのあるフ
ィールドは、選択された圧縮形式を指示するように指定
される。

【００３９】クイックタイムにより与えられる別のツー
ルは、図８に参照番号１７０で示されたムービーツール
ボックスである。これは、マッキントッシュコンピュー
タアプリケーションにおいてムービーを形成しそして再
生する全ての観点をアプリケーションが制御できるよう
にするファンクションを与える。幾つかのファンクショ
ンを以下に例示する。 （１）ＮｅｗＭｏｖｉｅ：メモリに新たなムービーを形
成する。 （２）ＮｅｗＭｏｖｉｅＴｒａｃｋ：新たなムービート
ラックを形成する。 （３）ＮｅｗＴｒａｃｋＭｅｄｉａ：トラックの新たな
媒体を形成する。 （４）ＮｅｗＭｏｖｉｅＦｒｏｍＦｉｌｅ：ムービーフ
ァイルに記憶されたリソースからメモリにムービーを形
成する。 （５）ＣｏｎｖｅｒｔＦｉｌｅｔｏＭｏｖｉｅＦｉｌ
ｅ：特定のファイルを取り出しそしてそれをムービーフ
ァイルへ変換する。 （６）ＳｔａｒｔＭｏｖｉｅ：現在ムービー時間から再
生してムービーをスタートする。 （７）ＡｄｄＭｅｄｉａＳａｍｐｌｅ：サンプルデータ
及び記述を媒体に追加する。 （８）ＧｅｔＭｅｄｉａＳａｍｐｌｅ：ムービーデータ
ファイルからサンプルを返送する。

【００４０】図８において、ムービーツールボックス１
７０は、音声データ１５２と、新たな圧縮装置１６９に
より圧縮されたアニメーションデータとを受け入れる。
多くのアニメーションアプリケーションにおいて、音声
データは圧縮されない。ムービーツールボックス１７０
は、これらのデータに基づいてムービー１７２を形成
し、そしてムービーは、ＣＤＲＯＭ１７４に記録され
る。又、ムービーツールボックス１７０は、ＣＤＲＯＭ
１７４に既に記録されたムービーを再生のために検索す
るのにも使用される。

【００４１】システム１５０の再生部分について説明す
る。ムービーツールボックス１７０は、ＣＤＲＯＭ１７
４からムービー１７２を検索する。これは、ムービーの
サウンドトラックから音声データを回復する。音声デー
タは、音声マネージャー１８４へ供給され、コンピュー
タ１９６が音声データに基づいて音声を再生するように
する。圧縮されたアニメーションデータは、像圧縮マネ
ージャーの圧縮解除ファンクション１８８へ供給され
る。圧縮解除ファンクション１８８は、像圧縮解除コン
ポーネント１９０をコールする。ここに示す実施形態に
おいて、新たな圧縮解除装置１９１は、各フレームごと
に異なるアルゴリズムを呼び出すことができるので、デ
ータを圧縮解除するために呼び出される。新たな圧縮解
除装置１９１は、上記の特定のフィールドに基づきフレ
ームを形成するのに使用された圧縮アルゴリズムの形式
を決定することができる。圧縮解除されたデータは、コ
ンピュータ１９６に像を描くマッキントッシュのクイッ
クドロールーチン１９２（又は他の所有のドローイング
ルーチン）へと送られる。

【００４２】図８に示すシステムは、ムービーの各フレ
ームごとに適当な圧縮装置／圧縮解除装置を選択できる
ことが明らかである。ネットワークシステム（ローカル
エリアネットワーク又はインターネット）における本発
明の実施について以下に説明する。図９は、本発明を実
施するのに使用できるネットワークシステム３５０を示
す図である。システム３５０は、ローカルエリアネット
ワーク又はワイドエリアネットワークであるデータ通信
ネットワーク３５２を含む。又、システム３５０は、複
数のクライエントコンピュータ（コンピュータ３５６−
３５８のような）及び複数のサーバコンピュータ（サー
バ３６６及び３６７のような）も含む。これらのコンピ
ュータは、複数のネットワークアクセスデバイス３６０
−３６４（クライエントコンピュータをダイヤルアップ
ラインに接続するためのモデム、及びサーバコンピュー
タをＴ１ラインに接続するためのチャンネルサービスユ
ニットのような）を用いてネットワーク３５２に接続さ
れる。好ましくは、圧縮されたフレームがサーバに記憶
される。圧縮されたフレームは、所定の時間に又は要求
があった際にクライエントコンピュータに送られる。デ
ータを受け取ると、クライエントコンピュータは、ムー
ビーを再生する。

【００４３】クライエントコンピュータ及びサーバの構
造は、図７のコンピュータシステム１００と同様でよ
い。典型的に、サーバは、クライエントコンピュータよ
りもパワフルである（記憶容量及び処理能力に関し
て）。ネットワークアクセスデバイスは、コンピュータ
（サーバ及びクライエント）をデータ通信ネットワーク
に接続するための従来の装置であり、従って、ここで
は、詳細に説明しない。

【００４４】本発明の１つの実施形態においては、フレ
ームの圧縮は、サーバの場所又はネットワークシステム
３５０以外の場所で実行することができる。次いで、フ
レームは、１つ以上のサーバに記憶される。たとえクラ
イエントコンピュータの場所で圧縮を行って記憶できた
としても、クライエントの場所は処理能力及び人間のリ
ソースが比較的限定されるので、一般的に好ましいやり
方ではない。

【００４５】クライエントコンピュータがアニメーショ
ンの再生を希望するときには、例えば、ウェブにおける
ハイパーテキスト搬送プロトコル（ＨＴＴＰ）を使用し
て、ムービーを記憶しているサーバに要求を送信する。
次いで、要求を発しているクライエントコンピュータに
フレームが送信される。次いで、クライエントコンピュ
ータは、フレームを圧縮解除して再生する。以上、特定
の実施形態を参照して本発明を詳細に説明した。本発明
の精神及び範囲から逸脱せずに種々の変更及び修正が明
らかとなろう。上記の説明及び添付図面は、単に本発明
を例示するものに過ぎず、本発明は、特許請求の範囲の
みによって限定されるものとする。

【図面の簡単な説明】

【図１】フレームの差をベースとする従来の方法を示す
図である。

【図２】フレームの差をベースとする従来の方法を示す
図である。

【図３】フレームの差をベースとする従来の方法を示す
図である。

【図４】本発明の実施形態を示すフローチャートであ
る。

【図５】スプライトをベースとする方法においてピクセ
ルごとの比較を使用する場合を示す図である。

【図６】スプライトをベースとする方法においてピクセ
ルごとの比較を使用する場合を示す図である。

【図７】本発明を実施するのに使用できるコンピュータ
システムのブロック図である。

【図８】クイックタイムを用いた本発明の実施形態を示
す回路図である。

【図９】本発明を実施するのに使用できるネットワーク
システムのブロック図である。

Claims (16)

【特許請求の範囲】
1. 【請求項１】 マルチメディアアニメーションにおける
   データのフレームを処理するのに使用される圧縮−圧縮
   解除方法において、 所定の基準を設定し、 上記データに関連したスプライトベースのフレームを形
   成し、 上記データと手前のフレームとのピクセルごとの比較を
   実行して、フレームの差をベースとするフレームを形成
   し、 上記スプライトベースのフレームの第１データレート
   と、上記フレームの差をベースとするフレームの第２デ
   ータレートを決定し、 上記第１及び第２のデータレートを上記所定の基準と比
   較し、そして上記スプライトベースのフレーム及び上記
   フレームの差をベースとするフレームの一方を圧縮され
   たフレームとして選択する、という段階を備えたことを
   特徴とする方法。
2. 【請求項２】 上記データがキーフレームに対応するか
   どうかを確認し、そして上記データがキーフレームであ
   る場合には、上記実行、上記決定、上記比較及び上記選
   択の段階を省略する請求項１に記載の方法。
3. 【請求項３】 上記選択されたフレームは、記憶媒体に
   記憶される請求項１に記載の方法。
4. 【請求項４】 ＣＤＲＯＭを備えた請求項３に記載の記
   憶媒体。
5. 【請求項５】 ネットワークサーバを備えた請求項３に
   記載の記憶媒体。
6. 【請求項６】 上記選択されたフレームは、データネッ
   トワークを経て送信される請求項１に記載の方法。
7. 【請求項７】 上記データネットワークは、インターネ
   ットである請求項６に記載の方法。
8. 【請求項８】 上記データネットワークは、ローカルエ
   リアネットワークである請求項６に記載の方法。
9. 【請求項９】 上記決定段階は、更に、上記スプライト
   ベースのフレームの第１ピクセルレートと、上記フレー
   ムの差をベースとするフレームの第２ピクセルレートを
   決定し、そして上記比較段階は、更に、上記第１及び第
   ２のピクセルレートを上記所定の基準と比較する請求項
   １に記載の方法。
10. 【請求項１０】 上記データがキーフレームに対応する
    かどうかを確認し、そして上記データがキーフレームで
    ある場合には、上記実行、上記決定、上記比較及び上記
    選択の段階を省略する請求項９に記載の方法。
11. 【請求項１１】 上記選択されたフレームは、記憶媒体
    に記憶される請求項９に記載の方法。
12. 【請求項１２】 ＣＤＲＯＭを含む請求項１１に記載の
    記憶媒体。
13. 【請求項１３】 ネットワークサーバを含む請求項１１
    に記載の記憶媒体。
14. 【請求項１４】 上記選択されたフレームは、データネ
    ットワークを経て送信される請求項９に記載の方法。
15. 【請求項１５】 上記データネットワークは、インター
    ネットである請求項１４に記載の方法。
16. 【請求項１６】 上記データネットワークは、ローカル
    エリアネットワークである請求項１４に記載の方法。