JP3706721B2 - オーディオビジュアル・ファイル内部での検索方法および検索装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、広くは、ビデオ・ファイルの編集の方法に関する。より詳しくは、本発明は、多重オーディオビジュアル・ファイル内部でのあらかじめ定められたビデオ・フレームの検索の各種方法および装置に関する。一側面にあっては、ファイル・バイト・オフセットを基準にして、ターゲット・フレームのデータを検索してアクセスする方法および装置が開示される。
【０００２】
【従来の技術】
ＭＰＥＧ（動画エキスパート・グループ）は、国際規格機構（ＩＳＯ）が定めたデジタル・ビデオおよびオーディオ信号を簡潔にあらわすための構文法に関する規格である。この構文法では、一般に、ビット・ストリームを符号化するときにしたがうべき規則の数を最小限にしてしかも受信したビット・ストリームを明確に復号できることが求められる。当業者には周知のように、ビット・ストリームは、ビデオおよびオーディオ構成要素に加えて「システム」構成要素を含むものである。一般に、システム構成要素は、各ビデオおよびオーディオ構成要素を組み合わせ同期させて単一のビット・ストリームにするために必要な情報を含んでいる。具体的には、システム構成要素によって復号器でのオーディオ／ビデオの同期が可能となる。
【０００３】
ＭＰＥＧ−１と呼ばれる最初のＭＰＥＧが公表された後、ＭＰＥＧ−２で知られる次のＭＰＥＧが導入された。一般的にいって、ＭＰＥＧ−２は、放送されるビデオをより効率的にあらわすことができる改良された構文法を規定したものである。成立の経緯から、ＭＰＥＧ−１では、1.５Ｍビット／秒の速度でデータを取り扱い、各フレームが３５２画素×２４０ラインの解像度のものを毎秒約３０ビデオ・フレーム（ＮＴＳＣ）または各フレームが３５２画素×２８８ラインの解像度のものを毎秒約２５ビデオ・フレーム（ＰＡＬ）再構成する場合に最適の結果が得られるものとなっている。したがって、復号されたＭＰＥＧ−１ビデオは、消費者のビデオテープ（ＶＨＳ）の知覚される品質にほぼ近似している。それに対して、ＭＰＥＧ−２は、4.０から8.０Ｍビット／秒のデータ速度でのＣＣＩＲ６０１の解像度をあらわしまた７２０画素×４８０ライン（ＮＴＳＣ）または７２０画素×５７６ラインのフレーム解像度をあたえるように設定されている。以下、簡単のために、これら二つのＭＰＥＧ規格の間の相違が問題となる場合をのぞいて、「ＭＰＥＧ」という用語は、現在規定されているおよび将来規定されるであろうビデオおよびオーディオ符号化および復号アルゴリズムをさすものとする。
【０００４】
通常、復号の過程は、ビデオ、オーディオ、およびシステム情報を含むＭＰＥＧビット・ストリームが符号化された個別のビデオおよびオーディオ・ビット・ストリームを生成する役割りを果たすシステム復号器によってデマルチプレクスされるときに始まる。なお、これらの符号化されたビデオおよびオーディオ・ビット・ストリームは、その後、ビデオ復号器およびオーディオ復号器で復号することができる。現在は、符号化されたビデオ・ビット・ストリームの構造に関心が向けられている。一般に、符号化されたＭＰＥＧビデオ・ビット・ストリームは、明確なデータ構造階層に組織される。この階層の最も高いレベルには「ビデオ・シーケンス」がある。これは、シーケンスヘッダ、１以上の画像グループ（ＧＯＰ）、およびシーケンスの終わりコードを含むものとすることができる。ＧＯＰは、ビデオ・シーケンスのサブセットであり、各ＧＯＰは、１以上の画像を含むことができる。以下に説明するように、ＧＯＰは、それによってビデオ・シーケンスのある画定されたセグメントにアクセスできるためきわめて重要である。ただし、ＧＯＰは、きわめて大きくなる場合がある。
【０００５】
１つのＧＯＰ内部の各画像は、左から右へまた上から下へ向けて画定されるいくつかの「スライス」に仕切られる。個々のスライスは、１６×１６画素の正方形の面積を占める１以上のマクロブロックで構成される。ＭＰＥＧ規格に記されているように、１つのマクロブロックは、四つの８×８画素「ルミナンス（輝度）」構成要素と二つの８×８「クロミナンス（色差）」構成要素（すなわち、クロマ赤およびクロマ青）を含む。
【０００６】
１つのＧＯＰ内部の画像の間では、画素情報の多くが類似しているかまたは同一であるため、ＭＰＥＧ規格は、この時間的冗長性を利用し、特定の基準画像から互いに異なる選ばれた画像をあらわすようにしている。ＭＰＥＧ規格は、大きく、三種類の符号化された画像フレームを定義している。第１の種類のフレームは、イントラ・フレーム（Ｉ−フレーム）である。Ｉ−フレームは、フレーム自身に含まれる情報を用いて符号化され、以前のまたは将来のフレームに含まれる情報には依存しない。その結果、Ｉ−フレームは、一般に、フレームのシーケンスの中の特定のＧＯＰの起点を定義する。
【０００７】
第二の種類のフレームは、予測フレーム（Ｐ−フレーム）である。Ｐ−フレームは、一般に、前のＩまたはＰ−フレームに含まれる情報を用いて符号化される。当業者には周知のように、Ｐ−フレームは、前方予測フレームと呼ばれる。第三の種類のフレームは、双方向フレーム（Ｂ−フレーム）である。Ｂ−フレームは、過去および未来のフレームの両方に含まれる情報にもとづいて符号化され、したがって双方向予測フレームと呼ばれる。したがって、Ｂ−フレームは、Ｉ−フレームおよびＰ−フレームより圧縮されたものとなる。ＭＰＥＧ規格は、ＩまたはＰ−フレームの間に特定の数のＢ−フレームを配置することを求めてはいないが、大部分の符号器は、ＩおよびＰ−フレームの間に二つのＢ−フレームを選択する。このような選択の設定は、符号器の中のメモリの量および符号化される材料に必要な特性および定義などの各種要因にもとづいて行なわれている。
【０００８】
【発明が解決しようとする課題】
ＭＰＥＧ規格は、ビデオおよびオーディオ・ビット・ストリームを簡潔に符号化するための便利な構文法を定めているが、符号化されたビット・ストリームのセグメントを切り取って新しいビット・ストリームで使用する場合にはかなりの困難が生じる。とくに、Ｐ−フレームは、ビット・ストリーム内の以前のフレームからの情報を使用し、またＢ−フレームは、以前と将来のフレームの両方からの情報を使用するため、切り取りは、Ｉ−フレームで行なわなければならない。すなわち、切り取られたセグメントは、その切り取られたセグメントの中に、Ｉ−フレームを開始フレームとしてまたＰまたはＩ−フレームを最終フレームとしてもっていなければならない。したがって、Ｉ−フレームで切り取りを行なうと、最初のビット・ストリームに含まれる基準フレームなしには復号することができない開始および終了フレームを有するビデオ・クリップが排除されることになる。
【０００９】
残念ながら、通常の符号化されたビデオ・ビット・ストリームは、Ｉ−フレームの間に多数のＰおよびＢ−フレームをもっている。その結果、切り取りが行なわれる場所が限定される不具合が生じ、符号化されたＭＰＥＧビット・ストリームは、フレームの精密さが求められるビデオ編集業に適さないものとなってしまう。
【００１０】
従来の編集エンジンに関連する他の不具合は、ターゲット・ビデオ・フレームの検索を行なうためには、ファイル内の各フレームを時間をかけて読み取って復号する必要があることである。すなわち、特定のビデオ・フレームの検索を行なう前に、編集プログラムがファイル内の各ビデオ・フレームを読み取って復号し、各フレームの時間的基準を判別する必要がある。各フレームが読み取られて復号されれば、ターゲット・フレームの検索を行なうことができる。残念ながら、大多数のビデオ・ファイルは、きわめて大きいものである。例えば、３時間のビデオ・ファイルは、フレーム・レートが毎秒３０フレームとすれば、約３２４０００ものビデオ・フレームを含むものとなる。ターゲット・フレームの検索を行なう前に３２４０００ものビデオ・フレームを各々読み取って復号するとすれば、それは、きわめて手間のかかる今日のビデオ編集作業には不適なものとなることは理解されよう。さらに、従来の検索アルゴリズムは、ビデオ・ファイル内のフレームの正確な数を確認する前にビデオ・ファイルを読み取って復号する必要がある。
【００１１】
以上の説明から、手間をかけて予めビデオ・ファイルの各フレームを読み取って復号することを必要とせずに、１つのビデオ・ファイル内部のターゲット・ビデオ・フレームの検索を効率的に行なうための方法および装置が求められている。
【００１２】
【課題を解決するための手段】
本発明の目的にもとづいて上の課題を解決するために、１つのオーディオビジュアル・ファイル内部のターゲット・ビデオ・フレームの検索を高速かつ効率的に行なうための方法および装置が開示される。１つの実施の形態にあっては、本発明の検索装置は、まず、オーディオビジュアル・ファイル内部のターゲット・フレームのバイトであらわした推定位置を判別する。バイトであらわした推定位置が判別されると、該推定位置からバイトであらわしたあらかじめ定められた秒数が差し引かれ、推定時間位置が示される。次に、検索装置は、ターゲット・ビデオ・フレームの少なくとも１つの画像グループ（ＧＯＰ）ヘッダだけ前にある推定時間位置まで飛び越しを行なう。
【００１３】
ここで、検索エンジンは、推定時間位置の前にある任意のＧＯＰヘッダへ進む。各ＧＯＰヘッダで、検索エンジンは、そのＧＯＰヘッダの時間コードから得られるフレーム番号がターゲット・フレームの番号より大きいか否かを判別する。ＧＯＰヘッダの時間コードから得られるフレーム番号がターゲット・フレームの番号より大きい場合には、検索エンジンは、前に読み取られて保管されたＧＯＰヘッダへ逆戻りする。この時点で、前のＧＯＰヘッダは、ターゲット・フレームを含んでいることが好ましい。ターゲット・フレームを識別するために、検索エンジンは、前のＧＯＰヘッダの時間コードから得られたフレーム番号をターゲット・フレーム番号から差し引いて、ＧＯＰヘッダ内部にターゲットの時間基準フレーム番号を生成する。これで検索エンジンは、ターゲット時間基準フレーム番号まで移動してターゲット・フレームの特定を行なうことになる。
【００１４】
検索エンジンがターゲット・フレームを識別したら、そのターゲット・フレームに関するファイル・バイト・オフセットがわかって記憶される。この記憶されたバイト・ファイル・オフセットを用いれば、任意のときにターゲット・フレームの検索を行ない、ターゲット・ビデオ・フレームに含まれるデータにアクセスすることができる。
【００１５】
他の一実施の形態にあっては、オーディオビジュアル・ファイルの中のビデオ・フレームの数を正確に判別することのできる検索エンジンが開示される。最初、検索エンジンは、オーディオビジュアル・ファイルの終わりを識別してそこへ移動する。終わりに達したら、検索エンジンは、あらかじめ定められた時間だけビデオ・ファイルの中のある位置まで逆戻りする。次に、検索エンジンは、時間的にファイルの前方へ移動して任意のＧＯＰヘッダを識別し、任意の識別されたＧＯＰヘッダが保管される。検索エンジンは、ファイルの終わりに達するまで時間的に前方へ移動しながらＧＯＰヘッダの識別と保管を続ける。終わりに達したら、検索エンジンは、前に保管したＧＯＰヘッダへ逆戻りする。前に保管したヘッダに達したら、検索エンジンは、該前に保管したＧＯＰヘッダに関連するあらかじめ定められた数のビデオ・フレーム画像ヘッダの各々を読み取って各ビデオ・フレームごとの時間基準フレーム番号を判別する。あらかじめ定められた数のビデオ・フレーム画像ヘッダの各々が読み取られるのに応じて、前の時間基準フレーム番号が現在の時間基準フレーム番号より大きいか否かが判別される。
【００１６】
検索エンジンは、この判別にもとづいて、前の時間基準フレーム番号より小さい時間基準フレーム番号を有するすべてのビデオ・フレームを無視する。ファイルの終わりに達した時点で、ビデオ・ファイルの中の（確認可能なフレーム番号をもつ）最後のフレームが、前に保管されたＧＯＰヘッダの中の最も大きい時間基準フレーム番号をもつフレームとして識別される。検索エンジンは、ファイルの中の各フレームを手間をかけて読み取りまた復号する必要なしに、ビデオ・ファイルの中のビデオ・フレームの数を正確に判別することができる。
【００１７】
本発明は、数多くの効果をもたらすが、とくに大きな効果は、ターゲット・ビデオ・フレームを検索する前あるいはオーディオビジュアル・ファイルのビデオ・フレームの数を判別する前に、手間をかけてオーディオビジュアル・ファイルの中の各ビデオ・フレームを読み取り、復号し、指標付けを行なう必要がないことである。
【００１８】
【発明の実施の形態】
本発明ならびにその効果は、添付の図面を参照して行なう以下の説明から最もよく理解されよう。
【００１９】
本発明は、広くは、オーディオビジュアル・ファイル内部での検索の方法および装置を開示するものである。検索エンジンは、手間をかけてオーディオビジュアル・ファイルの中の各ビデオ・フレームを読み取り、復号し、指標付けを行なう必要なしにターゲット・ビデオ・フレームを効率的に検索するように実装される。さらに、検索エンジンは、１つのビデオ・ファイルの中の最後のＧＯＰヘッダを識別し、さらに該ファイルの中の最後のビデオ・フレームを識別することによって、該ビデオ・ファイルの中のフレーム数を正確に判別することができる。ファイルの中の最後のビデオ・フレームは、各ビデオ・フレームの（すなわち、最後のＧＯＰ内部の）画像ヘッダを読み取り、どの画像ヘッダがより大きい時間基準フレーム番号を示すかを判別することによって識別される。すなわち、最大の時間番号をもつビデオ・フレームは、該ビデオ・ファイルの中の最後のビデオ・フレームである。さらに、検索エンジンは、識別されたビデオ・フレームを最も近いオーディオ・フレームと関係づけてオーディオ−ビデオ検索を完了することができる。
【００２０】
説明をわかりやすくするために、本発明の検索エンジンを、ビデオ・ファイルの編集との関連で説明する。ビデオの編集では、一般的に、オーディオビジュアル・ファイル内部の編集されたビデオ・セグメントの境界を画定するためにターゲット・ビデオ・フレームの検索を行なう必要がある。したがって、フレームに関して正確かつ効率的に検索を行なう方法および装置の必要性を理解するために、ビデオ・ファイルの編集の各種の方法を概観しておくことが有用であろう。「切り取り、コピー、マークイン、マークアウト」などの用語は、すべて、特定のビデオ・フレームを識別するための検索エンジンの実施の形態に関して用いられることを理解されたい。ターゲット・フレームが識別されたら、該ターゲット・フレームのデータの内容に高速でアクセスすることができる。
【００２１】
本発明の一実施の形態にあっては、ＭＰＥＧビット・ストリーム・ファイルからビデオのセグメントを切り取り、切り取られたセグメントの部分を処理して元のビット・ストリーム・ファイルに含まれる情報から独立した１つのビット・ストリーム・セグメントを生成するための方法が開示される。一般に、編集エンジンは、特定の編集作業を要求するアプリケーションに応じて提供されるオペレータ（演算子）の編集リストを使って二つの処理パスで独立のセグメントを生成するために編集対象セグメントを処理する。最初の処理パスでは、編集エンジンは、好ましくは切り取られたセグメントの始めと終わりにあるフレームの種類にもとづいて、該編集対象セグメント用のグル（のり付け）セグメントを生成する。第二の処理パスでは、最初のパスで生成されたすべてのグル・セグメントが編集対象セグメントの未処理部分に貼り付けられる。すべてのグル・セグメントと未処理部分が正しい時間順序で互いに貼り付けられると、貼り付けられたセグメントがアプリケーションへ送られる。貼り付けられたセグメントは、ビデオ・フレームを正確に復号するための最初のビット・ストリーム・ファイルの中に含まれている情報を必要としない。
【００２２】
図１は、ソース・ファイルに含まれるフレーム情報から独立したビデオ・フレーム・セグメントを生成することに関係する処理ステップを説明するために用いる多くのビデオ・フレームのシーケンスを示す図である。例として、フレームがＭＰＥＧ規格のフォーマットにもとづいて処理された後で符号化される順序を示すビデオ・フレームの符号化の順序のストリーム５０が示されている。例として示したこの符号化の順序のストリーム５０では、最初のフレームは、Ｉ−フレームであり、その後にＰ−フレーム、Ｂ−フレーム、Ｂ−フレーム、Ｐ−フレーム、Ｂ−フレーム、Ｂ−フレーム等々が続く。本発明の編集アルゴリズムは、任意の適当に配列されたフレームのシーケンスを処理することができるが、表示の順序でフレームのシーケンスを処理することが好ましい。
【００２３】
すなわち、フレーム０からフレーム３６まで時間順序で配列されたフレーム・ストリームは、表示順序ストリーム５２の中で処理されるフレームの順序を識別する。比較のために、符号化順序ストリーム５０の中のフレームの対応する時間順序を対応するフレームの下に示してある。もちろん、表示順序ストリーム５２は、単に例であり、本発明にもとづいて他の適当な表示順序ストリームを適当に処理できることは理解されよう。
【００２４】
ビデオ・フレームのセグメントが表示順序ストリーム５２から切り取られると、マークインの位置およびマークアウトの位置が設定されて、切り取られるフレームの番号がマークされる。例として、マークインの位置がＰ−フレームであるフレーム９に設定され、マークアウトの位置がＢ−フレームであるフレーム２８に設定されるとする。したがって、表示順序ストリーム５２から切り取られるフレームのセグメントは、フレーム９から２８までとなる。切り取りの大きさがきまると、フレーム９がＩ−フレームでなくフレーム２８がＩ−フレームまたはＰ−フレームでない場合には、切り取りの始めに、フレームは、Ｐ−フレーム９では過去のフレームからの情報を、またＢ−フレーム２８では過去および未来のフレームからの情報を必要とする。その結果、フレーム９から１４およびフレーム２５から２８は、予測型のフレームであり、表示順序ストリーム５２に残っているフレームから十分な情報（コンテキスト）を把握しないと復号することができないことになる。
【００２５】
ビデオ・フレームの切り取られた全セグメントを復号可能にするために、ビデオ・フレーム９から１４および２５から２８は、該切り取られた全セグメントを復号可能でかつ最初の表示順序ストリーム５２に含まれる情報から独立したものとする処理を受ける。例として、フレーム９から１４および２５から２８が復号されてＩ−フレームに再符号化された後に「ドラフト・モード」で処理されたセグメント５４を示す。便宜上、処理されたフレーム９から１４を「イン・グルセグメント」と呼び、フレーム２４から２８を「アウト・グルセグメント」と呼ぶ。さらに、未処理のフレーム１５から２３を「ミドル・グルセグメント」と呼ぶ。
【００２６】
本実施の形態にあっては、イン・グルおよびアウト・グルセグメントは、フレーム９より前のリファレンスフレームを編集対象セグメント内から削除したＩ−フレームに符号化されており、またＢ−フレーム２５、２６、２７、および２８も、フレーム２８より後のフレームに含まれる情報を必要としない。再符号化されたイン・グルおよびアウト・グルセグメントも、ＩおよびＰの組み合わせに符号化することができ、Ｉ−フレームは、切り取らとられた「Ｉ−Ｐモード」セグメント５６に示すイン・グルセグメントおよびアウト・グルセグメントの両方の始まりとなることができることは理解されよう。さらの他の一実施の形態にあっては、再符号化されたイン・グルおよびアウト・グルセグメントは、Ｉ−Ｐ−Ｂフレームに符号化して、Ｉ−フレームが、切り取られた「Ｉ−Ｐ−Ｂモード」セグメント５８に示すイン・グルセグメントおよびアウト・グルセグメントの両方の始まりとなることができる。セグメント５８が実施される場合には、Ｐ−フレーム間の距離（すなわち、フレームの数）を判別することが好ましい。さらに、上に述べた各モードのＧＯＰの大きさも判別することが好ましい。
【００２７】
以下に詳細に説明するように、マークインとマークアウトの位置の間の切り取るセグメントが選定されたら、マークインの位置がすでにＩ−フレームでなければ、マークインの位置から最も前のＩ−フレームが識別される。この例では、フレーム６が、表示順序ストリーム５２の最も前のＩ−フレームである。このようにして、ＭＰＥＧ復号器は、Ｉ−フレーム６を復号して、マークイン・フレーム−９を含みまたミドル・インフレーム１５の前の１フレームまで伸びるイン・グルセグメントの中でフレームを復号し再符号化するのに十分な情報を獲得することができる。例として、復号器が、Ｉ−フレーム６を画素ビットマップに復号して情報を獲得すると、処理が進行してフレーム９、１０、１１、１２、１３、および１４を復号し再符号化するように構成することができる。同様に、復号器はＩ−フレーム２４から十分な情報を獲得しているため、フレーム２５から２８も、個々に復号されまた再符号化される。したがって、フレーム２５、２６、２７、および２８も、再符号化されて、Ｉ−フレーム２４で始まる適当なアウト・グルセグメントを生成する。
【００２８】
図２は、本発明の一実施の形態にもとづくビデオ・ファイルの編集に用いられるデータ・フロー・アーキテクチャー１００を示す。図示のように、ファイルのオーディオ構成要素の編集にも同様なアーキテクチャー（例、かげになって隠されている部分）が用いられる。
【００２９】
図示の実施の形態にあっては、データ・フロー・アーキテクチャー１００は、多くの編集作業を行なうことのできる編集エンジン１０２（例、ＭＥＤＩＴ編集エンジン）によって駆動されることが好ましい。例として、この種の作業として、ソースまたは入力ストリームからのセグメントが他のファイルで使用するためにコピーされる必要があることを要求するコピー操作を挙げることができる。他の適当な編集作業としては、フェード操作、ブレンド操作、モーフィング（形付け）操作、ティルティング（傾け）操作、テキスト・アノテーション（注釈付け）操作などを挙げることができる。一般に、ＭＥＤＩＴエンジン１０２は、編集作業を要求するアプリケーションが提供するオペレータの種類に応じて異なる多くの編集作業を管理することのできるダイナミックなエンジンである。したがって、ＭＥＤＩＴエンジン１０２は、複雑高度な編集作業を必要とする将来のアプリケーションが提供するオペレータを含む多数のオペレータの種類をすべて管理することができることが理解されよう。
【００３０】
以下では、ソース・ファイルからビデオのセグメントをコピーするなどの編集作業を行なう場合にＭＥＤＩＴエンジン１０２がたどる処理ステップの概要を説明する。一般に、コピー操作は、アプリケーション１０６がコピー操作を行なうことを要求したときに開始される。
【００３１】
最初、アプリケーション１０６は、ＭＥＤＩＴエンジン１０２に、編集する型を要求するためのチャンネル番号を識別する複数の「チャンネル・オペレータ」１１０、アプリケーション１０６が要求する編集機能の種類を識別する「機能オペレータ」１１２、および編集要求の終わりを識別する「終端オペレータ」１１４を含む適当な編集リスト１０８を提供する。図示の実施の形態では、機能オペレータ１１２は、「コピー」要求を識別する。例として、機能オペレータ１１２で識別された最初のコピー要求は、チャンネル１であるＡ．ＭＰＥＧと呼ばれるファイルの中のフレーム９から２８をコピーする要求であるとする。図示のように、チャンネルＮであるＢ．ＭＰＥＧと呼ばれるファイルの中のフレーム１０から５０をコピーする要求に至るまで、他にも多くのコピーの要求があり得る。
【００３２】
ＭＥＤＩＴエンジン１０２が編集リスト１０８を受け取ると、コピーの要求が編集リスト１０８を通る二つの識別可能なパスで処理される。最初のパスでは、ＭＥＤＩＴエンジン１０２は、編集リスト１０８全体を通読してコピーされた各セグメントのためにイン・グルまたはアウト・グルセグメントが必要か否かを識別する。もちろん、マークインおよびマークアウト・フレームがともにＩ−フレームであれば、イン・グルまたはアウト・グルセグメントは必要ではない。しかし、マークイン・フレームがＩ−フレームでないか、あるいはマークアウト・フレームがＰまたはＩ−フレームでない場合には、そのコピーされたセグメントのためにグル・セグメントが生成されることになる。コピーされたセグメントのためにグル・セグメントが生成される場合には、該グル・セグメントは、適当な記憶媒体１４０に記憶される。記憶媒体１４０は、キャッシュ・メモリ、コンピューター・ハード・ドライブ、フロッピー・ディスク、あるいは適当なネットワークによって接続されて遠隔に配置された記憶媒体など任意の適当な記憶媒体とすることができる。
【００３３】
第二のパスでは、ＭＥＤＩＴエンジン１０２は、ＭＥＤＩＴエンジン１０２によって生成される複数のスティッチャ・オブジェクト１４７、１４８を用いてグル（のり）部分を未処理のコピーされたセグメント（すなわち、ミドル・グル）と接合することで前に生成したグル・セグメントを利用する。以下により詳細に説明するように、スティッチャ・オブジェクトは、編集リスト１０８の各チャンネルのために生成され、特定のチャンネルに関連して生成された各スティッチャ・オブジェクトは、編集リスト１０８全体をみてそれ自身のチャンネルのためにグル・セグメントを接合する（例、他のチャンネルに関連する情報は無視する）能力をもつ。
【００３４】
このようにして、編集リスト１０８の中で識別された各チャンネルのために多数のスティッチャ・オブジェクトを生成することができる。特定の一実施の形態にあっては、各スティッチャ・オブジェクトは、正しい時系列で該特定のグル・セグメントを接合し、生成された各セグメントが適当な表示順序ストリームを生成するようにタイムスタンプを押す能力をもつ。さらに、生成された各スティッチャ・オブジェクトは、グル・オブジェクト１３０および１３１などのグル・オブジェクトを用いて、前に生成されたイン・グルまたはアウト・グルファイルからグル・セグメントを引き出すか、あるいはミドル・グルセグメントの位置を識別するポインタを用いて元のファイルからミドル・グルを引き出す。図１は、好ましくはフレーム１５から２３を含むミドル・グルセグメントの例を示している。貼り付けられたフレーム・データがプログラム要素ストリーム（ＰＥＳ）としてマルチプレクサ１５０に出力されると、マルチプレクサ１５０は、生成されたすべてのスティッチャ・オブジェクトからＰＥＳデータを引き出し、コピーされたセグメントをＭＥＤＩＴ１０２を介してアプリケーション１０６へ出力する。
【００３５】
図２の全体のデータの流れを説明するために、アプリケーション１０６が、チャンネル１からＡ．ＭＰＥＧファイル１２４（すなわち、図１の表示順序ストリーム５２）からフレーム９から２８をコピーする操作を要求する場合を仮定する。ＭＥＤＩＴエンジン１０２は、最初のパスの間に全編集リスト１０８を通読して、前の編集要求の間にグル・セグメントがすでに生成されてグル・ファイルの中に記憶されているか否かを判別する。Ａ．ＭＰＥＧファイル１２４からのフレーム９から２８のコピー操作のためにすでに存在するグル・セグメントはないと仮定すると、ＭＥＤＩＴエンジン１０２は、制御オブジェクト１１１（例、ダイレクト−イン オブジェクト）を生成するコピー・オペレータ１０４を生成する。
【００３６】
この実施の形態にあっては、制御オブジェクト１１１は、検索エンジン１１８を使用して、Ａ．ＭＰＥＧファイル１２４の中でコピーするために識別された適当なビデオ・フレームを検索する。特定のターゲット・ビデオ・フレームを検索することに関係するアルゴリズムは、図３から図８を参照して以下にさらに詳細に説明する。適当なフレームが検索されると、復号器は、最も前のＩ−フレーム６を復号して、復号器１２０にイン・グルセグメント内部のフレームを処理するための適当な情報（コンテキスト）を提供する。復号器１２０が適当な情報を獲得すると、フレーム９は、復号器１２０によって復号され、画素ビットマップに変換され、これがコピー・オペレータ１０４へ送られる。
【００３７】
コピー・オペレータ１０４は、ビットマップ情報を、コピー・オペレータ１０４によって生成し符号器１１５を有する制御オブジェクト１１３（例、ダイレクト−アウト オブジェクト）へ送る。符号器１１５は、再符号化されたフレームをＡ．ＭＰＥＧグル・ファイル１２６の中に記憶しているグル・オブジェクト１１６を呼び出す。図示のように、Ａ．ＭＰＥＧグル・ファイル１２６は、キャッシュ・メモリなどの記憶媒体１４０の中に記憶されている。フレーム９がＩ−フレームに再符号化されると、フレーム１０から１４も同様にして再符号化され、Ａ．ＭＰＥＧグル・ファイル１２６などの「イン・グル」ファイルを生成する。
【００３８】
ＭＥＤＩＴエンジン１０２は、通常、編集リスト１０８の中の各コピー要求のために個別のコピー・オペレータを生成することは理解されよう。したがって、編集リストの中の第二のコピー操作要求（すなわち、Ｂ．ＭＰＥＧファイル、チャンネルＮからのフレーム１０から５０）は、個別のコピー・オペレータ１０４によって処理され、これらのコピー・オペレータが、それ自身の検索および復号機能のために新しい制御オブジェクト１１１を生成し、また生成されたグル・フレームを符号化しておそらくは記憶媒体１４０に記憶されている他のグル・ファイルへ転送するための新しい制御オブジェクト１１３を生成する。
【００３９】
一実施の形態にあっては、各コピー・オペレータの実行は、編集リスト１０８の中で識別されたすべての編集要求を迅速に処理する並行フォーマットの多重処理ユニットによって処理することができる。さらに、編集リストの中にはきまった評価順序は存在せず、また各編集操作は独立に行なうことができるので、並行処理は容易である。他の一実施の形態にあっては、インターネット・ビデオ・サーバーを用いて多重処理を行なうことができる。当業者には周知のように、インターネット・ビデオ・サーバーは、編集リスト１０８の中の編集要求を同時に処理するために用いることができる。
【００４０】
やはり図２を参照して、編集リスト１０８の中の各コピー要求のために適当なグル・ファイルが生成されたら、ＭＥＤＩＴエンジン１０２は、第二のパスで編集リスト１０８を通読し、編集リスト１０８の中で識別された各チャンネルのためにスティッチャ・オブジェクト１４７および１４８を生成する。図示の例では、チャンネル１およびチャンネルＮのために生成された二つのスティッチャ・オブジェクトのみが示されているが、編集リスト１０８の中で識別されたチャンネルの数に応じて任意の数のスティッチャ・オブジェクトを生成できることは理解されよう。例として、実施の形態によっては、ＭＰＥＧ−２プラットホームの下の約４０００のビデオ・チャンネルおよび約８０００のオーディオ・チャンネルの多重チャンネルのためのスティッチャ・オブジェクトを含むようにすることができるものもある。
【００４１】
各チャンネルのためにスティッチャ・オブジェクトが生成されると、各スティッチャ・オブジェクト１４７および１４８は、グル・オブジェクト１３０および１３１を生成することが好ましい。この実施の形態にあっては、各スティッチャ・オブジェクトは、編集リストを通読して関連するチャンネルのための編集要求をさがす。例として、スティッチャ・オブジェクト１４７は、編集リスト１０８を通読してチャンネル１のための編集要求を識別し、同様に、スティッチャ・オブジェクト１４８は、編集リスト１０８を通読してチャンネルＮのための編集オペレータを識別する等々の構成とされる。グル・オブジェクト１３０および１３１が生成されると、グル・オブジェクト１３０は、各スティッチャ・オブジェクト１４７および１４８に、最初のパスの間に生成されたグル・データを提供する。
【００４２】
この例では、グル・オブジェクト１３０は、コピーされたセグメントのために各種のグル・セグメントを引き出す任務をもつ。例として、グル・オブジェクト１３０は、Ａ．ＭＰＥＧグル・ファイル１２６の中に記憶されたグル・データを引き出してそれをスティッチャ・オブジェクト１４７に提供するものとすることもできる。さらに、なんらかのミドル・グルデータ（すなわち、切り取られたセグメントの未処理部分）が要求された場合、グル・オブジェクト１３０は、制御オブジェクト１１１によって制御されるストリーマ１２２へのポインタ１３４を用いる。このようにして、グル・オブジェクト１３０は、Ａ．ＭＰＥＧファイル１２４から正しいフレームを引き出すことができる。この実施の形態にあっては、ミドル・グルは、図１の表示順序ストリーム５２内のフレーム１５から２３に関連させることができる。したがって、各スティッチャ・オブジェクト１４７および１４８は、グル・データを要求し、グル・オブジェクト１３０および１３１は、適当な位置からデータを引き出す。各スティッチャ・オブジェクトが、時系列的に要求されたデータを引き出すと、各スティッチャ・オブジェクトは、ＰＥＳデータ・ストリームをＭＵＸユニット１５０へ転送し、該ユニットは、引き出されたＰＥＳデータ・ストリームを多重化して、単一のストリームをＭＥＤＩＴ１０２を介してアプリケーション１０６へ送る。
【００４３】
図３は、本発明の一実施の形態にもとづいてビデオ・ファイル内部でターゲット・フレームを検索することに関係するステップを示すフローチャートである。この方法では、ステップ６００でビデオ・ファイルのフレーム・レートを求める。一般に、ビデオ・ファイルのフレーム・レートは、多重ファイルのビデオ部分のシーケンスヘッダ、とくに最初のビデオ・パケットのヘッダから求められる。上に述べたように、ビデオ・ファイルのフレーム・レートは、ＮＴＳＣでは毎秒約３０ビデオ・フレームであり、ＰＡＬでは毎秒約２５ビデオ・フレームである。
【００４４】
ステップ６００でビデオ・ファイルのフレーム・レートを求めたら、ステップ６０２へ進み、ビデオおよびオーディオをともに含むファイルのビット・レートを求める。当業者には周知のように、ビット・レートは、多重ストリームの中の最初のパックのパックヘッダ（例、ＭＵＸビット・レート）から求められる。ステップ６０２で１秒あたりのビット数としてのビット・レートが求められたら、ステップ６０４へ進み、ビデオ・ファイルの終わりから「バイト」であらわしたビデオ・ファイルの大きさが判別される。例として、適当な操作システムを用いれば、通常は、バイトであらわした読み取りファイルの大きさを確認することができる。したがって、ステップ６０４では、好ましくは、オペレーティング・システムによって多重ビデオ／オーディオ・ファイルの大きさがあたえられる。
【００４５】
ステップ６０４でビデオ／オーディオ・ファイルの大きさが判別されたら、ステップ６０６へ進み、ビデオ・ファイルの全フレーム数の推定が行なわれる。例として、フレーム数は、ファイルの大きさにフレーム・レートを「掛け」、その積をビット・レートで割ることによって推定することができる。
【００４６】
表１
フレーム数の推定値
Ｓ＝ファイルの大きさ（バイト数）
Ｂ＝ビット・レート（バイト数／秒）
Ｒ＝フレーム・レート（フレーム数／秒）
Ｔ＝全フレーム数の推定値（フレーム）
Ｔ＝Ｓ×Ｒ／Ｂ
ステップ６０６で上に示した式にもとづいて全フレーム数の推定値を求めたら、ステップ６０８へ進み、ビデオ／オーディオ・ファイル内部のターゲット・ビデオ・フレームのバイト数であらわした時間位置を推定する。ビデオ・ファイル内部のターゲット・ビデオ・フレームの時間位置を推定するためには、ターゲット・ビデオ・フレーム番号にビット・レートを掛けて、フレーム・レートで割る。次に、求めた時間位置から１秒のバイト数を引いて、ターゲット・フレームの実際の位置の前にある位置に到達するようにする。
【００４７】

ビデオ・ターゲット・フレームの推定時間位置（ＥＴＰ）は、ステップ６０８で上に示した式を用いて求められることは理解されよう。処理は、次にステップ６１０へ進み、次のＧＯＰヘッダを読み取って、一時メモリ、例えばキャッシュ・メモリあるいは他の適当な記憶媒体に保管する。例として、次のＧＯＰヘッダは、推定時間位置のすぐ後のＧＯＰヘッダであることが好ましい。ステップ６１０で次のＧＯＰヘッダが保管されたら、処理は、決定ステップ６１２へ進み、次のＧＯＰヘッダ時間コードが、ターゲット・フレーム番号より大きいフレーム番号を示すか否かが判別される。
【００４８】
例として、ターゲット・フレーム番号が、フレーム番号５５２５であり、ＧＯＰヘッダ時間コードが、フレーム番号５４５０を示したとすると、示されたフレーム番号は、ターゲット・フレーム番号より小さいことになる。当業者には周知のように、ＧＯＰヘッダが読み取られると、該ＧＯＰヘッダの中のＳＭＰＴＥ時間コードを読み取ることでフレーム番号が示される場合がある。ＭＰＥＧの資料に示されているように、ＧＯＰヘッダに含まれるＳＭＰＴＥ時間コードを読み取って復号するために、任意の適当な周知のアルゴリズムを用いることができる。より詳しくは、ＭＰＥＧ資料「動画および関連オーディオの符号化」−−約1.５Ｍビット／秒までのデジタル記憶媒体用（第２部）、２−付録Ｅ、ＩＥＣ規格、刊行物４６１、第二版、「ビデオ・テープ・レコーダー用時間および制御コード」（１９８６）（MPEG document "Coding of Moving Pictures and Associated Audio"--For digital storage media at up to about 1.5 Mbots/s (Part 2), 2-annex E, IEC Standard, Publication 461, second edition, entitled "Time and Control Code For Video Tape Recorders" ）を参照されたい。ＭＰＥＧ資料は、すべて、参考資料として本出願に添付されている。
【００４９】
したがって、次のＧＯＰヘッダ時間コードがターゲット・フレーム番号より大きくないフレーム番号を示すと判別された場合には、処理は、ステップ６１０へ戻って、上に述べたように次のＧＯＰヘッダが読み取られて保管される。次に、処理は、再びステップ６１２へ進んで、次のＧＯＰヘッダ番号がターゲット・フレーム番号より大きいフレーム番号を示すか否かが再び判別される。他方、ＧＯＰヘッダ時間コードが、ターゲット・フレーム番号より大きいフレーム番号を示すと判別された場合には、処理は、ステップ６１４へ進む。
【００５０】
ステップ６１４では、処理が１ＧＯＰヘッダだけ逆戻りし、ＧＯＰヘッダを「ターゲットＧＯＰヘッダ」として識別する。すなわち、ターゲットＧＯＰヘッダは、ターゲット・フレーム番号を含むＧＯＰを画定するものである。さらに、前に読み取られた各ＧＯＰヘッダは保管されているので、１フレームの逆戻りは、単に処理を逆転させて保管されているＧＯＰへ戻ることにしか過ぎない。このようにして、ＧＯＰヘッダ時間コードは、ターゲット・フレーム自身のフレーム番号かまたは少なくともターゲット・フレーム番号より大きくないフレーム番号を示すことになる。
【００５１】
ステップ６１４で処理が１ＧＯＰヘッダだけ逆戻りしてＧＯＰヘッダをターゲットＧＯＰヘッダとした後、処理は、ステップ６１６へ進み、ターゲット・フレーム番号を検索するためにターゲットＧＯＰ内部のあらかじめ定められた数のフレームを読み取る。あらかじめ定められたターゲット・フレームの数が読み取られると、ターゲット・フレームが識別され、処理が完了する。
【００５２】
図４は、ターゲットＧＯＰ内部であらかじめ定められた数のフレームを読み取ってターゲット・フレーム番号の検索を実行することに関係する処理ステップをより詳細に示した図である。処理は、ステップ６１８から始まり、このステップでは、ターゲット画像グループ（ＧＯＰ）内部の次のフレームの画像ヘッダが読み取られる。上に述べたように、ＧＯＰヘッダは、一般に、Ｉ−フレームで始まるある数のビデオ・フレームの始まりを画定する。ターゲットＧＯＰ内部の最初のフレームのための画像ヘッダが読み取られたら、処理は、決定ステップ６２０へ進み、現在のフレームの時間表示番号にターゲットＧＯＰヘッダ（例、ＳＭＰＴＥ時間コード）から得られるフレーム番号を加えたものがターゲット・フレーム番号に等しいか否かが判別される。
【００５３】
現在の時間基準フレーム番号にターゲットＧＯＰヘッダから得られるフレーム番号を加算したものがターゲット・フレーム番号に等しくないと判別された場合には、処理は、再びステップ６１８へ進み、次のフレームの画像ヘッダが読み取られて復号される。ステップ６１８で次のフレームの画像ヘッダが読み取られて復号されると、処理は、再び決定ステップ６２０へ進む。決定ステップ６２０では、もう一度、現在の時間基準フレーム番号にターゲットＧＯＰヘッダから得られるフレーム番号を加えたものがターゲット・フレーム番号に等しいか否かが判別される。この条件が満たされる場合には、処理は、ステップ６２２へ進んでターゲット・フレームが識別され、ターゲット・フレームの検索を実行する処理が完了する。
【００５４】
ターゲット・フレームが識別されると、当該ターゲット・フレームのファイル・バイト・オフセットがわかり、記憶される。本明細書で使用する限りにおいて、ファイル・バイト・オフセットという用語は、ビデオ・ファイルの中でのファイルの始めに対するターゲット・フレームの位置として定義される。すなわち、ターゲット・フレームは、「０」バイト（すなわち、オフセットなし）に設定されるファイルの始めから判別されたバイト数である「ファイル・バイト・オフセット」だけファイル内に入り込んだ位置に位置ぎめすることができる。ターゲット・フレームに関するファイル・オフセットが知られているため、必要な場合には、単にターゲット・フレームの記憶されているファイル・バイト・オフセットを求めるだけで、ターゲット・フレームの内容に迅速にアクセスしてその内容を読み取ることができる。
【００５５】
図５は、例として、本発明の一実施の形態の始点と終点をもつビデオ・ファイル７０２を示す線図である。図３のステップ６０８で説明したように、検索エンジンは、最初、飛び越しによってビデオ／オーディオ・ファイルの中の推定時間位置まで進む。図５に示すように、ビデオ・ファイルの中の推定位置への飛び越しが完了すると、ＧＯＰヘッダ７１０から得られるフレーム番号がターゲット・フレーム（例、ターゲット・フレーム５５２５）より大きいか否かが判別される。この例では、ＧＯＰヘッダ７１０は、ターゲット・フレーム５５２５より大きいビデオ・フレーム番号を示さない。
【００５６】
したがって、処理は、次のＧＯＰヘッダ７１２へ進み、再び、ＧＯＰヘッダ時間コードが例として挙げたターゲット・フレーム５５２５より大きいフレーム番号を示すか否かが判別される。説明のために、ＧＯＰヘッダ７１２から得られるフレーム番号が、再び、ビデオ・ターゲット・フレーム番号５５２５より大きくないと判別されたとする。処理は、もう一度次のＧＯＰヘッダ７１４へ進むが、このＧＯＰヘッダも、ターゲット・フレームより大きいフレーム番号を示さない。処理は、さらに次のＧＯＰヘッダ７１６へ進む。この時点で、ついに、ＧＯＰヘッダ時間コードが、ターゲット・ビデオ・フレーム５５２５より大きいフレーム番号を示すと判別される。本発明の一実施の形態にあっては、図３のステップ６１４で説明したように、処理は、前の保管ＧＯＰヘッダ７１４へ逆戻りする。
【００５７】
図５の拡大した７０４に示すように、ＧＯＰヘッダ７１４の後には多数のビデオ・フレームが続いている。すなわち、これら複数のビデオ・フレームが、画像グループを画定し、この画像グループは、Ｉ−フレーム５５２３（時間基準フレーム番号２）、Ｂ−フレーム５５２１（時間基準フレーム番号０）、Ｂ−フレーム５５２２（時間基準フレーム番号１）、Ｐ−フレーム５５２６（時間基準フレーム番号５）、Ｂ−フレーム５５２４（時間基準フレーム番号３）、およびＢ−フレーム５５２５（時間基準フレーム番号４）を有する。ＭＰＥＧ規格に記されているように、ＧＯＰヘッダ７１４のＳＭＰＴＥ時間コードから得られるフレーム番号は、矢印で示すＢ−フレーム５５２１である。これらさまざまな検索操作が行なわれている間、ビデオ・ファイルは、「符号化順序」にしたがっていることが理解されよう。しかし、各種の時間基準フレーム番号によって、適当な「表示順序」のどれかが識別されることになる。
【００５８】
ＧＯＰヘッダ７１４から得られるフレーム番号は、フレーム番号５５２１であるため、検索エンジンは、ターゲット・フレーム５５２５から４フレームだけ離れていることになる。したがって、検索エンジンは、４番目の時間基準フレーム番号を識別する処理へ進む。この例では、４番目の時間基準フレーム番号は、「ターゲット・フレーム５５２５」である。図５の拡大した７０４に示すように、ターゲット・フレーム５５２５は、Ｂ−フレームである。
【００５９】
図６Ａは、本発明の一実施の形態における多重ビデオ／オーディオ・ファイル内のビデオ・フレーム数を効率的に判別するための処理ステップを示すフローチャートである。処理は、ステップ８００で始まり、このステップでは、ビデオおよびオーディオ・ファイルの終わりがバイト数で識別される。上に述べたように、一般的に、任意の適当なオペレーティング・システムにおいては、通常のファイルを読み取り、その終わりを長さとして判別することができる。ステップ８００でビデオ・ファイルの終わりが判別されると、処理は、ステップ８０２へ進み、検索エンジンは、バイト数で１秒だけ逆戻りする。説明をわかり易くするために、図６Ｂには、図６Ａのフローチャートを用いて説明する開始時間と終了時間をもつファイル８５０の例を示してある。
【００６０】
上に述べたように、検索エンジンは、好ましくは、例として示したファイル８５０の終わりからバイト数で１秒逆戻りして、点８５１に達する。検索エンジンがバイト数で１秒逆戻りすると、処理は、ステップ８０４へ進み、次のＧＯＰヘッダが読み取られて保管される。例として、ファイル８５０では、次のＧＯＰヘッダは、ＧＯＰヘッダ８５４として示されている。
【００６１】
次に、処理は、決定ステップ８０６へ進み、検索エンジンが前方へ移動して、ビデオ・ファイルの中に次のＧＯＰヘッダがあるか否かを判別する。例として示したファイル８５０は次のＧＯＰヘッダ８５６を含んでいるため、検索エンジンは、次のＧＯＰヘッダ８５６へ進み、このＧＯＰヘッダが、図６Ｂに示すように適当に読み取られて保管される。次に、処理は、再び決定ステップ８０６へ進み、検索エンジンが前方へ移動して、ビデオ・ファイルの中に次のＧＯＰヘッダがあるか否かを判別する。
【００６２】
ビデオ・ファイルの中にはもうＧＯＰヘッダはないので、処理は、ステップ８０８へ進み、検索エンジンは、前に保管したＧＯＰヘッダ８５６へ逆戻りする。この時点で、検索エンジンは、ファイルの中の最後のＧＯＰヘッダを識別している。したがって、ファイルの中の最後のビデオ・フレームはＧＯＰ８５６内部に置かれている。図６Ｂに示すように、検索エンジンが前に保管したＧＯＰヘッダ８５６へくると、処理は、ステップ８１０へ進み、ＧＯＰヘッダ８５６に続く各フレームの画像ヘッダが読み取られる。このようにして、読み取られた各画像ヘッダの時間基準フレーム番号が判別されて保管される。
【００６３】
図６Ｂの例として示したファイル８５０では、次のフレームは、時間基準フレーム番号「２」をもつ「Ｉ」フレーム１５，５２３である。この番号は、一時的にメモリに保管される。処理は、ステップ８１２へ進み、次のフレームの画像ヘッダが読み取られ、時間基準フレーム番号が判別される。図６Ｂに示すように、次のフレームは、時間基準フレーム番号「０」をもつ「Ｂ」フレーム１５，５２１であり、この番号は、保管される。この時点で、「前の」時間基準フレーム番号「２」と「現在の」時間基準フレーム番号「０」が保管されたことになる。
【００６４】
次に、処理は、決定ステップ８１４へ進み、「現在」の時間基準フレーム番号「０」が「前の」時間基準フレーム番号「２」より大きいか否かが判別される。現在の時間基準フレーム番号「０」は前の時間基準フレーム番号「２」より大きくないので、処理は、ステップ８１５へ進み、他の画像ヘッダがあるか否かが判別される。他の画像ヘッダは存在しないので、処理は、ステップ８１６へ進み、現在の時間基準フレーム番号「０」をもつフレームは、無視される。
【００６５】
処理は、再びステップ８１２へ進み、次の画像ヘッダが読み取られ、その時間基準フレーム番号が判別される。次のフレームは、時間基準フレーム番号「１」をもつ「Ｂ」フレームである。この時点で、「現在の」時間基準フレーム番号は「１」であり、「前の」時間基準フレーム番号は「２」である。ここで、処理は、決定ステップ８１４へ進み、「現在の」時間基準フレーム番号「１」が前の時間基準フレーム番号「２」より大きいか否かが判別される。現在の時間基準フレーム番号は前の時間基準フレーム番号より大きくないので、処理は、ステップ８１５へ進み、他の画像ヘッダがあるか否かが判別される。
【００６６】
他の画像ヘッダは存在しないので、処理は、ステップ８１６へ進む。上に述べたように、現在の時間基準フレーム番号は無視されれ、処理は、再びステップ８１２へ進む。ステップ８１２では、時間基準フレーム番号「５」をもつ「Ｐ」フレーム１５，５２６の画像ヘッダが読み取られる。この時点で、「現在の」時間基準フレーム番号は「５」であり、「前の」時間基準フレーム番号は「２」である。
【００６７】
ここで再び、処理は、決定ステップ８１４へ進み、「現在の」時間基準フレーム番号「５」が前の時間基準フレーム番号「２」より大きいか否かが判別される。現在の時間基準フレーム番号は前の時間基準フレーム番号より大きいので、処理は、ステップ８１７へ進み、前の時間基準フレーム番号「２」をもつフレームは無視される。即ち、現在の時間基準フレーム番号「５」が前の時間基準フレーム番号「２」より大きいため、検索エンジンは、ファイルの中の最後に表示されるフレームの識別により近づくことになる。ファイルの中の最後に表示されるフレームが、ファイル内部に含まれるビデオ・フレームの正確な合計数を示すものであることはいうまでもない。ファイルの中の最後に表示可能なフレームは、「Ｐ」フレーム１５，５２６であるが、検索エンジンは、上に述べたように、残るフレームを読み取ってこのことを確認しなければならない。
【００６８】
したがって、処理は、決定ステップ８１８へ進み、他にも画像ヘッダが存在するか否かが判別される。他にも存在するため、処理は、ステップ８１２へ進み、次の画像ヘッダが読み取られ、時間基準フレーム番号が判別される。図６Ｂに示すように、次のフレームは、時間基準フレーム番号「３」をもつ「Ｂ」フレーム１５，５２４である。したがって、「現在の」時間基準フレーム番号は「３」であり、「前の」時間基準フレーム番号は「５」である。
【００６９】
ここで、処理は、決定ステップ８１４へ進み、「現在の」時間基準フレーム番号「３」が前の時間基準フレーム番号「５」より大きいか否かが判別される。この場合、現在の時間基準フレーム番号「３」は前の時間基準フレーム番号「５」より大きくないので、処理は、ステップ８１５へ進み、他の画像ヘッダがあるか否かが判別される。他の画像ヘッダは存在するので、処理は、ステップ８１６へ進み、現在の時間基準フレーム番号「３」をもつフレームは、無視される。処理は、次にステップ８１２へ進み、次の画像ヘッダが読み取られ、その時間基準フレーム番号が判別される。
【００７０】
図６Ｂに示すように、次のフレームは、時間基準フレーム番号「４」をもつ「Ｂ」フレームである。したがって、「現在の」時間基準フレーム番号は「４」であり、「前の」時間基準フレーム番号は「５」である。ここで、処理は、決定ステップ８１４へ進み、現在の時間基準フレーム番号が前の時間基準フレーム番号より大きいか否かが判別される。この場合、現在の時間基準フレーム番号「４」は前の時間基準フレーム番号「５」より大きくない。次に、処理は、ステップ８１５へ進み、他の画像ヘッダがあるか否かが判別される。
【００７１】
図６Ｂの例では、「Ｂ」フレーム１５，５２５の後には画像ヘッダは存在しないので、処理は、ステップ８１９へ進み、現在の時間基準フレーム番号「４」をもつフレームは、無視される。この時点で、残る唯一のフレームは、時間基準フレーム番号「５」をもつ「Ｐ」フレーム１５，５２６である。これで、検索エンジンは、時間基準フレーム番号が最も大きい画像ヘッダをもつフレームを確認し、それより小さい時間基準フレーム番号をもつフレームはすべて無視したことになる。
【００７２】
処理は、次に、ステップ８２０へ進み、識別された時間基準フレーム番号が、ＧＯＰヘッダＳＭＰＴＥ時間コードから判別されたフレーム番号に加えられる。上に述べたように、ＭＰＥＧ資料に示されておりまた参考資料として本出願に添付した周知のアルゴリズムを用いて、ＧＯＰヘッダＳＭＰＴＥから絶対フレーム番号を判別することができる。ＭＰＥＧ資料に示されているように、得られる絶対フレーム番号は、「Ｂ」フレーム１５，５２１である。
【００７３】
フレームが識別されたら、それが、上に識別した時間基準フレーム番号「５」に加えられる。即ち、最後のフレーム番号は、（１５，５２１＋５＝１５，５２６）である。この時点で、検索エンジンは、「Ｐ」フレームをフレーム番号「１５，５２６」をもつ最後のフレームとして正しく識別したことになる。検索エンジンは、ファイルの中の各フレームを手間をかけて読み取って復号する必要なしに、図６Ｂに例として示したファイル８５０の中のビデオ・フレームの数を正確に判別したことになる。
【００７４】
図７は、本発明の一実施の形態における、複数のオーディオおよびビデオ・パケットをもつシステム・ストリーム９００を示す線図である。図７は、「システム・クロック」のシステム・ストリーム９００内部でターゲット・ビデオ・フレーム９１８の位置を判別するための図８に記した処理ステップを視覚的に示す図である。ターゲット・ビデオ・フレーム９１８の位置が判別されれば、最も近いオーディオ・フレームを識別することができ、それによって「オーディオ−ビデオ」検索が完了する。
【００７５】
ＭＰＥＧ資料に記載されているように、ビデオおよびオーディオ構成要素がともに確実に同期化されるようにするためのタイミング機構が配設される。一般的に、ＭＰＥＧ規格は、システム・クロック基準（ＳＣＲ）および同期を維持しまた適当な再生を確保するために３３ビットを用いて符号化された再生タイムスタンプ（ＰＴＳ）をともに識別する。さらに、システム・クロックは、一般に、約９０ｋＨｚで作動する。
【００７６】
完全さのために、図７は、システム・ストリームの左端に位置するオーディオ・パケット９０２、および、それに続くビデオ・パケット９０４、その後のビデオ・パケット９０６、その後の他のビデオ・パケット９０８、およびその後のオーディオ・パケット９１０を示す。また、ビデオ・パケット９０４を拡大して、パケット・ヘッダ９１１、複数の画像ヘッダ９１２、９１４、および９１６を識別したものも示されている。この例では、画像ヘッダ９１６が、ターゲット・ビデオ・フレーム９１８の画像ヘッダである。
【００７７】
図８のフローチャートに示すオーディオ−ビデオ検索を行なうための処理は、ステップ９５０で始まり、このステップで、ターゲット・ビデオ・フレーム９１８の画像ヘッダ９１６とビデオ・パケット・ヘッダ９１１の間に配置されている画像ヘッダの数が判別される。この例では、画像ヘッダの数は、「２」であると判別される。すなわち、画像ヘッダ９１２および９１４である。もちろん、ターゲット・ビデオ・フレーム画像ヘッダ９１６とビデオ・パケット・ヘッダ９１１の間に配置されている画像ヘッダがない場合には、画像ヘッダの数は、「０」である。
【００７８】
次に、処理は、ステップ９５２へ進み、図７のパケット・ヘッダ９１１から「フレームあたりのシステム・クロック」であらわしたビデオ・パケットタイムスタンプが読み取られる。「フレームあたりのシステム・クロック」としてのビデオ・パケットタイムスタンプは、任意のビデオ・フレーム周波数を用いて判別することができる。例として、３０フレームのフレーム周波数を用いた場合には、フレームあたりのシステム・クロックは、下の表から判別することができる。
【００７９】

次に、処理は、ステップ９５４へ進み、「ビデオ・フレームあたりのシステム・クロック」（すなわち、３，０００）にターゲット・ビデオ・フレーム画像ヘッダ９１６とビデオ・パケット・ヘッダ９１１の間に配置されている画像ヘッダの数が乗算される。ステップ９５０で判別されたように、この例では、「２」つの画像ヘッダが配置されている。したがって、フレームあたりの３，０００システムクロックに２フレームが乗算され、６，０００システム・クロックの値が得られる。次に、パケットタイムスタンプに関するクロック数が６，０００システム・クロックに加算され、システム・クロックであらわしたターゲット・ビデオ・フレーム画像ヘッダ９１６の位置が示される。この時点で、検索エンジンは、例として示した図７のファイル９００内部のどこに、システム・クロックであらわしたターゲット・ビデオ・フレーム９１８が存在するかをすでに判別している。
【００８０】
他方、ステップ９５０で、ターゲット・ビデオ・フレーム画像ヘッダ９１６とビデオ・パケット・ヘッダ９１１の間に配置されている画像ヘッダが存在しないと判別されると、フレームあたり３，０００のシステム・クロックに「０」が乗算され、システム・クロックの数は０となる。したがって、ターゲット・ビデオ・フレーム画像ヘッダ９１６のためのシステム・クロックは、「パケットタイムスタンプ」自身に関するシステム・クロックのみとなる。この時点で、検索エンジンは、パケット・ヘッダ９１１とターゲット・ビデオ・フレーム画像ヘッダ９１６の間に存在する画像ヘッダのない特殊な場合においても、例とし示した図７のファイル９００内部のどこに、システム・クロックであらわしたターゲット・ビデオ・フレーム９１８が存在するかをすでに判別している。
【００８１】
ターゲット・ビデオ・フレーム９１８のシステム・クロックであらわした位置が判別されると、処理は、ステップ９５６へ進み、判別されたシステム・クロックの合計が一時メモリに保管される。あるいは、適当なポインタを用いて、システム・クロックであらわしたターゲット・フレームの位置を示すこともできる。次に、処理は、ステップ９５８へ進み、システム・クロックであらわしてターゲット・ビデオ・フレーム９１８に最も近いオーディオ・フレームを含むオーディオ・パケットが識別される。例として、最も近いオーディオ・パケットは、最も先行するオーディオ・パケットであることが好ましい。図７の例では、これは、オーディオ・パケット９０２である。ただし、他の実施の形態にあっては、最も近いオーディオ・フレームは、例えばオーディオ・パケット９１０のような、その後に続くオーディオ・パケットにあるとすることもできる。
【００８２】
ステップ９５８で適当なオーディオ・パケットが識別されると、処理は、ステップ９６０へ進み、ビデオ・パケットについて上に説明したとほぼ同様にして適当なオーディオ・パケット内での検索が行なわれる。もちろん、選ばれたオーディオ・パケット内部でのオーディオ・フレームの適当な位置を求めるためには、特定のＭＰＥＧオーディオ規格、オーディオ・フレーム・レートおよびオーディオ・ビット・レートが用いられる。この時点で、「オーディオ−ビデオ」検索を行なう処理は完了する。
【００８３】
本発明では、コンピュータ・システムに記憶されたデータを用いるさまざまなコンピュータが実行する操作が用いられる。これらの操作は、物理量の物理的処理を必要とする操作である。通常、これらの量は、記憶、転送、組み合わせ、比較、その他の処理が可能な電気信号または磁気信号の形をとるが、必ずしもそれに限定されるものではない。さらに、行なわれる処理は、生成、識別、判別、または比較などと呼ばれる場合が多い。
【００８４】
本明細書に記載されまた本発明の一部をなす操作は、すべて、有用なマシン・オペレーションである。本発明は、また、これらの操作を行なうための装置に関するものである。装置は、必要な目的の達成のために特別につくることもできるし、あるいは、コンピュータに記憶されているコンピュータ・プログラムによって選択的に活性化されあるいは構成される汎用コンピュータとすることもできる。とくに、本発明の開示内容にもとづいて書かれたコンピュータ・プログラムには、さまざまな汎用マシンを用いることもできるし、あるいは、必要な操作を行なうためのより専門的な装置をつくるのが好便な場合もある。本発明の構成例を以下に示す。
【００８５】
図９は、本発明にもとづく処理を行なうためのコンピュータ・システム１３００の例を示すブロック線図である。コンピュータ・システム１３００は、デジタル・コンピュータ１３０２、表示画面（モニター）１３０４、プリンタ１３０６、フロッピー・ディスク・ドライブ１３０８、ハード・ディスク・ドライブ１３１０、ネットワーク・インターフェース１３１２、およびキーボード１３１４を含む。デジタル・コンピュータ１３０２は、マイクロプロセッサ１３１６、メモリ・バス１３１８、ランダム・アクセス・メモリ（ＲＡＭ）１３２０、読み取り専用メモリ（ＲＯＭ）１３２２、周辺バス１３２４、キーボード・コントローラ１３２６を含む。デジタル・コンピュータ１３０２は、パーソナル・コンピュータ（例えば、ＩＢＭコンパティブルなパーソナル・コンピュータ、マッキントッシュ・コンピュータ、またはマッキントッシュ・コンピュータとコンパティブルなコンピュータ）、ワークステーション・コンピュータ（例えば、サン・マイクロシステムズまたはヒューレット・パッカードのワークステーション）、あるいは他の種類のコンピュータとすることができる。
【００８６】
マイクロプロセッサ１３１６は、汎用デジタル・プロセッサで、コンピュータ・システム１３００の操作を制御する。マイクロプロセッサ１３１６は、１−チップのプロセッサとすることもできるし、あるいは多数の構成要素で実装することもできる。マイクロプロセッサ１３１６は、メモリから検索された命令を用いて、入力データの受信と処理、および出力装置へのデータの出力と表示を制御する。本発明に関しては、マイクロプロセッサ１３１６の特定の機能として、ＭＰＥＧビデオおよびオーディオ・ストリーム内部での検索に関係する処理を補助する機能を挙げることができる。
【００８７】
メモリ・バス１３１８は、マイクロプロセッサ１３１６がＲＡＭ１３２０およびＲＯＭ１３２２にアクセスするために使用する。ＲＡＭ１３２０は、マイクロプロセッサ１３１６が一般記憶域としてまたスクラッチ・パッド・メモリとして使用し、また、入力データおよび処理ずみデータを記憶するために使用することもできる。ＲＯＭ１３２２は、マイクロプロセッサ１３１６が実行する命令およびプログラム・コードならびに他のデータを記憶するために用いることができる。
【００８８】
周辺バス１３２４は、デジタル・コンピュータ１３０２が入力、出力、および記憶装置にアクセスするために用いられる。記載の実施の形態にあっては、これらの装置は、表示画面１３０４、プリンタ装置１３０６、フロッピー・ディスク・ドライブ１３０８、ハード・ディスク・ドライブ１３１０、およびネットワーク・インターフェース１３１２を含む。キーボード・コントローラ１３２６は、キーボード１３１４から入力を受け取り、押された各キーの復号されたシンボルをバス１３２８を介してマイクロプロセッサ１３１６へ送るために用いられる。
【００８９】
表示画面１３０４は、マイクロプロセッサ１３１６によって周辺バス１３２４を介して供給されるか、またはコンピュータ・システム１３００の他の構成要素によって供給されるデータの映像を表示する出力装置である。プリンタ装置１３０６は、プリンタとして作動する場合には、紙などの上に映像を出力する。プリンタ装置１３０６の代わりにあるいはそれに加えて、プロッター、タイプセッター等々の他の出力装置も使用することができる。
【００９０】
フロッピー・ディスク・ドライブ１３０８およびハード・ディスク・ドライブ１３１０は、各種のデータを記憶するために用いることができる。フロッピー・ディスク・ドライブ１３０８は、各種データの他のコンピュータ・システムへの移送を容易にし、ハード・ディスク・ドライブ１３１０は、記憶されている大量のデータへの高速アクセスを可能にする。
【００９１】
マイクロプロセッサ１３１６は、オペレーティング・システムと組み合わされて、コンピュータ・コードを実行し、データを生成しまた使用する。これらのコンピュータ・コードおよびデータは、ＲＡＭ１３２０、ＲＯＭ１３２２、またはハード・ディスク・ドライブ１３１０に常駐することができる。コンピュータ・コードおよびデータは、また、取りはずし自在のプログラム媒体に常駐し、また、必要なときにはコンピュータ・システム１３００にロードまたはインストールすることができる。取りはずし自在のプログラム媒体は、例えば、ＣＤ−ＲＯＭ、ＰＣ−ＣＡＲＤ、フロッピー・ディスク、および磁気テープを含む。
【００９２】
ネットワーク・インターフェース１３１２は、他のコンピュータ・システムに接続されたネットワークを介してデータを送受信するために用いられる。インターフェース・カードまたは類似の装置およびマイクロプロセッサ１３１６によって実装された適当なソフトウエアを用いれば、コンピュータ・システム１３００を現存のネットワークへ接続し、標準プロトコルにしたがってデータを転送することができる。
【００９３】
キーボード１３１４は、ユーザーがこれを用いてコマンドおよび他の命令をコンピュータ・システムへ入力するものである。本発明に関連して他の種類の入力装置を使用することもできる。例えば、コンピュータ・マウス、トラック・ボール、スタイラス（尖筆）、またはタブレットなどの指示具を用いて、汎用コンピュータの画面上のポインタを操作することもできる。
【００９４】
本発明は、コンピュータが読み取り可能な媒体上のコンピュータが読み取り可能なコードとして実施することもできる。コンピュータが読み取り可能な媒体とは、データを記憶することができ、そのデータを後にコンピュータ・システムで読み取ることのできる任意のデータ記憶装置を意味する。コンピュータが読み取り可能な媒体としては、例として、読み取り専用メモリ、ランダム・アクセス・メモリ、ＣＤ−ＲＯＭ、磁気テープ、光学データ記憶装置を含む。コンピュータが読み取り可能な媒体は、また、ネットワークで連結された複数のコンピュータ・システムに分散させて、コンピュータが読み取り可能なコードが分散式に記憶され実行されるようにすることもできる。
【００９５】
上に説明したＭＰＥＧオーディオおよびビデオ規格で、参考資料として本出願に添付するものは以下の通りである。すなわち、（１）「動画および関連するオーディオ情報の総称的符号化：ビデオ」、ＩＳＯ／ＩＥＣ１３８１８−２（"Generic Coding of Moving Pictures and Associated Audio Information: Video," ISO/IEC 13818-2）と題する文書、（２）「デジタル記憶媒体のための、約1.５Ｍビット／秒までの動画および関連するオーディオの符号化」（第１部システム、第２部ビデオ、第３部オーディオ）１１１７１／１１１７２（１９９５／１９９６）（"Coding of Moving Picutres and Associated Audio for Digital Storage Media at up to about 1.5 MBit/s" (Part 1 System, Part 2 Video, Part 3 Audio) 11171/11172 (1995/1996)）、と題する文書、および（３）「動画および関連するオーディオ情報の総称的符号化」、１３８１８−３（"Generic Coding of Moving Pictures and Associated Audio Information" ISO/IEC 13818-3）と題する文書である。上に挙げたＭＰＥＧ規格文書および将来のＭＰＥＧ規格文書は、すべて、スイス国ジュネーブ２０、ＣＨ−１２１１、ＩＳＯ／ＩＥＣ私書箱５６（ ISO/IEC Case Postale 56, CH-1211, Geneva 20, Switzerland ）に依頼すれば、入手可能である。
【００９６】
以上、本発明の好ましい実施の形態を詳細に説明したが、本発明は、その意図および範囲を逸脱することなく他の形態で実施できるも理解されよう。説明した実施の形態では分散型アーキテクチャーが記載されている。この種のアーキテクチャーは、とくにモジュール構成の面からまた新しい機能の導入の面から多くの効果をもつ。例えば、単に検索エンジン、復号器等々多くの同じ構成要素を利用することのできる追加の「プラグ・イン」オペレータオブジェクトを配設することによって、新しい機能を生成することができる。さらに、上に述べた検索機能は、ＭＰＥＧ以外の規格によって定義されたオーディオビジュアル・ファイル内部でターゲット・フレームを検索し識別するためにも用いることができる。
【００９７】
上に述べたようなアーキテクチャーは、とくによく機能すると考えられるが、他のアーキテクチャーを用いても同様な機能を得られることは、理解されよう。したがって、上に述べた例および実施の形態は、単に例示であって本発明を制限するものではなく、本発明は、本明細書に記されている詳細に限定されず、添付の特許請求の範囲内で修正が可能であると思料すべきでものある。
【００９８】
【発明の効果】
本発明は、数多くの効果をもたらすが、とくに大きな効果は、ターゲット・ビデオ・フレームを検索する前あるいはオーディオビジュアル・ファイルのビデオ・フレームの数を判別する前に、手間をかけてオーディオビジュアル・ファイルの中の各ビデオ・フレームを読み取り、指標付けを行なう必要がないことである。
【図面の簡単な説明】
【図１】本発明の一実施の形態にもとづいたビデオ・ファイルの編集に関係する処理ステップを説明するために示した多数のビデオ・フレーム・シーケンスの例である。
【図２】本発明の一実施の形態にもとづいたビデオ・ファイルの編集を示すデータ・フロー・アーキテクチャーの図である。
【図３】本発明の一実施の形態にもとづいたビデオ・ファイル内部でのターゲット・フレームの検索に関係するステップを示すフローチャートである。
【図４】本発明の一実施の形態にもとづいたあらかじめ定められた数のフレームの読み取りに関係する方法のステップを説明する図である。
【図５】本発明の一実施の形態にもとづいたビデオ・ファイルを示す線図である。
【図６Ａ】本発明の一実施の形態にもとづいた多重オーディオビジュアル・ファイルの中のビデオ・フレームの数を効率的に判別するための方法のステップを示すフローチャートである。
【図６Ｂ】本発明の一実施の形態にもとづいたビデオ・ファイルの例を示す図である。
【図７】本発明の一実施の形態にもとづいた多数のオーディオおよびビデオ・パケットを有するシステム・ストリームを示す線図である。
【図８】本発明の一実施の形態にもとづいたオーディオ−ビデオ検索を行なうことに関係する方法のステップを示すフローチャートである。
【図９】本発明の一実施の形態にもとづいたオーディオビジュアル編集および検索ステップを行なうためのコンピューター・システムの例を示すブロック線図である。
【符号の説明】
１００…データ・フロー・アーキテクチャー、１０２…編集エンジン、１０４…コピー・オペレータ、１０６…アプリケーション、１０８…編集リスト、１１０…チャンネル・オペレータ、１１１…制御オブジェクト、１１２…機能オペレータ、１１３…制御オブジェクト、１１４…終端オペレータ、１１５…符号器、１１６…グル・オブジェクト、１１８…検索エンジン、１２０…復号器、１２２…ストリーマ、１２４…ＭＰＥＧファイル、１２６…ＭＰＥＧグル・ファイル、１３０，１３１…グル・オブジェクト、１３４…ポインタ、１４０…記憶媒体、１４７，１４８…スティッチャ・オブジェクト、１５０…マルチプレクサ、７０２…ビデオ・ファイル、７１０，７１２，７１４，７１６…ＧＯＰヘッダ、８５０…ファイル、８５４，８５６…ＧＯＰヘッダ、９００…システム・ストリーム、９０２…オーディオ・パケット、９０４，９０６，９０８…ビデオ・パケット、９１０…オーディオ・パケット、９１１…パケット・ヘッダ、９１２，９１６…画像ヘッダ、９１８…ターゲット・ビデオ・フレーム、１３００…コンピュータ・システム、１３０２…デジタル・コンピュータ、１３０４…表示画面、１３０６…プリンタ、１３０８…フロッピー・ディスク・ドライブ、１３１０…ハード・ディスク・ドライブ、１３１２…ネットワーク・インターフェース、１３１４…キーボード、１３１６…マイクロプロセッサ、１３１８…メモリ・バス、１３２０…ランダム・アクセス・メモリ、１３２２…読み取り専用メモリ、１３２４…周辺バス、１３２６…キーボード・コントローラ、１３２８…バス。

Claims (6)

1. 複数の画像グループを有するオーディオビジュアル・ファイルのバイトサイズと、前記オーディオビジュアル・ファイルのビット・レートおよびフレーム・レートとを用いて、次式（１）により、前記オーディオビジュアル・ファイルに含まれる全フレーム数を推定する第１のステップと、
   Ｔ＝Ｓ×Ｒ／Ｂ・・・・・・・・・・・・（１）
   式中、Ｔ＝全フレーム数の推定値（フレーム）
   Ｓ＝ファイルの大きさ（バイト数）
   Ｂ＝ビット・レート（バイト数／秒）
   Ｒ＝フレーム・レート（フレーム数／秒）
   前記全フレーム数と、前記オーディオビジュアル・ファイルのバイトサイズと、検索対象の目的のフレーム番号とを用いて、次式（２）により、検索対象の目的のフレームの推定時間位置をバイト数で求める第２のステップと、
   ＥＴＰ＝Ｆ×Ｓ／Ｔ ・・・・・・・・・（２）
   式中、ＥＴＰ＝ターゲット・ビデオ・フレームの推定時間位置
   Ｆ＝ターゲット・フレーム番号
   Ｓ＝ファイルの大きさ（バイト数）
   Ｔ＝全フレーム数の推定値（フレーム）
   前記バイト数に基づいて、前記オーディオビジュアル・ファイル内の検索対象の目的の前記推定時間位置を含む画像グループの先頭にアクセス開始位置を位置付ける第３のステップと、
   を含むことを特徴とするオーディオビジュアル・ファイル内部での検索方法。
2. 請求項１記載のオーディオビジュアル・ファイル内部での検索方法において、
   前記オーディオビジュアル・ファイルの前記ビット・レートおよび前記フレーム・レートは、前記オーディオビジュアル・ファイルの再生時のビット・レート、およびフレーム・レートからなることを特徴とするオーディオビジュアル・ファイル内部での検索方法。
3. 請求項１記載のオーディオビジュアル・ファイル内部での検索方法において、
   前記第３のステップでは、前記第２のステップで得られた前記バイト数の位置から、所定の時間分のバイト数だけ前記オーディオビジュアル・ファイルの先頭側に逆上った位置に前記アクセス位置を位置付け、当該アクセス開始位置以降に存在する各フレームのフレーム番号と、前記検索対象の目的の前記フレーム番号の大小関係を判定する操作を各フレーム毎に反復して、目的の前記フレーム番号の前記フレームの先頭部分にアクセス開始位置を位置付けることを特徴とするオーディオビジュアル・ファイル内部での検索方法。
4. 複数の画像グループを有する編集対象のオーディオビジュアル・ファイルが格納される第１の記憶媒体と、
   オーディオビジュアル・ファイルのバイトサイズと、前記オーディオビジュアル・ファイルのビット・レートおよびフレーム・レートとを用いて、次式（１）により、前記オーディオビジュアル・ファイルに含まれる全フレーム数を推定する第１のステップと、
   Ｔ＝Ｓ×Ｒ／Ｂ・・・・・・・・・・・・（１）
   式中、Ｔ＝全フレーム数の推定値（フレーム）
   Ｓ＝ファイルの大きさ（バイト数）
   Ｂ＝ビット・レート（バイト数／秒）
   Ｒ＝フレーム・レート（フレーム数／秒）
   前記全フレーム数と、前記オーディオビジュアル・ファイルのバイトサイズと、検索対象の目的のフレーム番号とを用いて、次式（２）により、検索対象の目的のフレームの推定時間位置をバイト数で求める第２のステップと、
   ＥＴＰ＝Ｆ×Ｓ／Ｔ ・・・・・・・・・（２）
   式中、ＥＴＰ＝ターゲット・ビデオ・フレームの推定時間位置
   Ｆ＝ターゲット・フレーム番号
   Ｓ＝ファイルの大きさ（バイト数）
   Ｔ＝全フレーム数の推定値（フレーム）
   前記バイト数に基づいて、前記オーディオビジュアル・ファイル内の検索対象の目的の前記推定時間位置を含む画像グループの先頭にアクセス開始位置を位置付ける第３のステップと、によって、前記記憶媒体の前記オーディオビジュアル・ファイル内部の任意の編集対象データを選択的に切り出して任意の第２の記憶媒体に保管する操作を行う検索制御部と、
   前記第２の記憶媒体に保管された前記編集対象データを読出して、任意のオーディオビジュアル・ファイルの一部に組み込んで出力する操作を行う編集制御部と、
   を含むことを特徴とするオーディオビジュアル・ファイル内部での検索装置。
5. 請求項４記載のオーディオビジュアル・ファイル内部での検索装置において、
   前記検索制御部は、
   前記オーディオビジュアル・ファイルが、それ自体で独立して復号可能な第１のフレームと、過去のフレームのデータに依存する第２のフレームと、過去および未来のフレームの双方のデータに依存する第３のフレームとを含む場合、
   前記編集対象データの先頭部分の前記フレームが過去または過去および未来のフレームのデータに依存する前記第２または第３のフレームである時、より過去のフレームのデータを含めた復号化および前記第１のフレームへの再符号化を行う第１の操作、
   前記編集対象データの後端部分が、前記フレームが未来のフレームのデータに依存する第３のフレームである時、より未来の前記フレームのデータを含めた復号化および前記第１または第２のフレームへの再符号化を行う第２の操作、
   の少なくとも一方の操作を実行することを特徴とするオーディオビジュアル・ファイル内部での検索装置。
6. 請求項４または５記載のオーディオビジュアル・ファイル内部での検索装置において、
   前記検索制御部および前記編集制御部は、外部から与えられる編集制御情報が格納された編集リストに基づいて、任意のオーディオビジュアル・ファイルからの前記編集対象データの切り出し操作および組み込み操作を自動的に実行する機能を備えたことを特徴とするオーディオビジュアル・ファイル内部での検索装置。

Images