JP2002507375A - デジタルビデオストリームをスプライスするための装置および方法 - Google Patents

Abstract

(57)【要約】 スプライシングシステムは、デジタル式に符号化されたデータストリームを共にシームレスにスプライスするためのスプライサーを含む。好ましい実施例では、このスプライサーは必要な場合に初期ＧＯＰを閉じる、スプライスアウトポイントおよびスプライスインポイントに対するデータストリームのデータの連続するスプライスフバッファを分析することが好ましい。この好ましいスプライサーは更に、新データストリームの符号化／提示を整合するための新データストリームのリアルタイムのＰＣＲ値を探し、新データストリームの開始時間を整合させる。同時にスプライサーは、フレームテーブルを使ってオーバーフローを検出し、ゼロパケットを追加し、よってデータストリームのデータの部分を遅延することにより、かかるオーバーフローを訂正することが好ましい。更に、スプライサーはゼロパケットを削除し、よってデータストリームのデータの一部を加速することによって、データストリームの符号化を回復することも好ましい。別の好ましい実施例では、スプライサーはビットクロックのスケジュールオフセットを使用し、データストリームのデータの部分を遅延または加速することが好ましい。

Description

【発明の詳細な説明】 デジタルビデオストリームをスプライスするための装置および方法 発明の分野 本発明は、一般的にはマルチメディアデータストリームの処理に関し、より詳 細にはデジタル式に符号化されたマルチメディアデータストリームを共にスプラ イスするための装置および方法に関する。 発明の背景 マルチメディアの創造、処理および配信システムは技術的進歩および早期の規 格化の努力によって促進されながら、急速に勃興しつつある。例えば改良された 処理および記憶、伝送、符号化／復号化およびその他の技術はアナログ放送から デジタル放送（すなわちデジタル化された、多くはデジタル処理されたマルチメ ディアデータストリームのテレビ、ケーブル、衛星放送およびその他の配信）へ のシフトを促進しつつある。早期の規格化は相互の運用性を可能にし、よってよ り安価な、より容易に入手できるシステムおよび部品を提供しつつある。このよ うなアナログからデジタルへのシフトによる予想される利点として業界用の、よ り種々の、より高品位のプログラムおよび高品位のマス分配メディアへ消費者が アクセスできるようになったことが挙げられる。 オーディオ、ビデオ、その他のマルチメディアおよび非マルチメディア情報を 含むデータストリームの符号化および復号化のための規格として動画エキスパー トグループによって支持されている国際的に採用されたＭＰＥＧ−１（ＩＳＯ／ ＩＥＣ１１１７２−ｎ）およびＭＰＥＧ−２（ＩＳＯ／ＩＥＣ１３８１８−ｎ） 仕様（ＭＰＥＧ−２は放送用品位のビデオおよびその他のアプリケーションのた めにＭＰＥＧ−１で拡張されたものである）が挙げられる。他の特徴のうちでも 、ＭＰＥＧ−１およびＭＰＥＧ−２（以下、ＭＰＥＧ仕様と総称する）のような 符号化／復号化仕様はハードウェア／ソフトウェアのシステムの実装とは基本的 に独立した一連のデータストリームフォーマット、タイミング、同期化およびデ バイス能力のパラメータを定めている。言い換えれば、ＭＰＥＧ仕様は所定のプ ロ トコルおよび機能を実装するための実質的に制約されない（かつ希望的には進歩 し続ける）システムを可能にしながら、特定のプロトコルおよび機能について規 定している。 これらＭＰＥＧ仕様およびその他の符号化／復号化規格も他の新しく出現する 技術を包含するように拡張されている。例えばオーディオ拡張規格（ＩＳＯ−Ｉ ＥＣ１３８１８−７）は、ＡＣ−３オーディオモードをＭＰＥＧ−２に加えてい る。データの符号化、復号化、伝送およびその他の関連する問題のユーティリテ ィを取り扱い、促進し、および／または拡張するための国際規格として、ＭＰＥ Ｇ仕様の範囲内の別の拡張も検討され、導入され、および／または採用されてい る。従って、以下、本明細書ではこれらＭＰＥＧ仕様を全く同じ用語で引用する こととする。 不幸なことに上記目標を達成するための、成長しつつある基礎を提供しながら 最近の開発を後に検討することにより、ＭＰＥＧおよび関連する仕様の少なくと も一部の草稿が必ず作成される。従って、改定および拡張にも係わらず、これら 規格は所定の予想されないアプリケーションおよびその他の偶発的な事項に関し て、必ず欠陥がある。例えばＭＰＥＧ−２は、完全にデジタル式に符号化された データストリームのスプライシングをサポートをするための増大する条件を予想 できなかった。広義に述べれば、デジタル式に符号化されたデータストリームの スプライシングは現在あるデータストリーム内の選択された点に新データストリ ームを添付し、スプライスポイントで現在のデータストリームを置換するように なっている。放送メディアに関して、スプライシングは現在放送されているデー タストリームから新データストリームへの切り替えとして広く検討できる。例え ば他のアプリケーションのうちでも特に、進行中の映画の放送に別個に符号化さ れたコマーシャルメッセージを挿入する必要性（コマーシャルのスタート時にス プライスを必要とし、コマーシャルの終了時に映画へ戻る別のスプライスが必要 である）が存在し得る。 アナログまたは符号化されていないデジタルデータストリームを共にスプライ スする、よりストレートフォワードな作業と比較すれば、デジタル式に符号化さ れたデータストリームを共にスプライスすることに関連する問題は、より容易に 理解できよう。例えば符号化されていないデータストリームは一般に、送信され 、受信機により受信され、バッファ化され、同じ順序でディスプレイされる。更 に、符号化されていないデータストリームの各個々に示されたデータ部分、すな わちフレームは、一般に同じでないにしても、同じ量のデータを含む。従って、 ２つのアナログデータストリームまたは符号化されていない２つのデジタルデー タストリームを共にスプライスするには、実質的に容易に決定できるフレームの 境界部で、あるストリームソースから第２のストリームソースへの切り替えを行 う。当技術分野でも、かかるスプライシングを実行するためのシステムおよび方 法は周知である。 これと対照的に、デジタル式に符号化されたデータストリームのフレームは、 一般にディスプレイされる順序とは異なる順序で復号器によって受信される。実 際には、異なる符号器は、かなり異なるフレームおよび情報特性を有するデータ ストリームを一般に発生する。更に、符号化の主な目的はデータストリームが他 の利点のうちでも特に伝送バンド幅が狭く、記憶スペースが少なくてすむように 、データストリームを圧縮することにある。従って、ＭＰＥＧ−２で符号化され たビデオデータストリームは、対応する画像（一般にＩフレームと称される）を 独立して再生するための、完全なデータを含む限られた数のフレームしか有する ことなく、予測フレーム（Ｐフレーム）および双方向フレーム（Ｂフレーム）と 一般に称される他のフレームは、先に復号化されたフレームと比較することによ り、ビデオ画像を再生するために、より少ない可変量の基準データを含む。更に 、（復号化中の）復号器のバッファは連続的に復号化するために充分な数のフレ ームを連続的に含むだけでなく、復号器のバッファをオーバーフローするのに、 多くない数のフレームも含む。 デジタル式に符号化されたデータストリームを共にスプライスすることは、符 号化された各データストリームの独立した特徴によって更に複雑となっている。 各データストリームに関連した、独立した形態および同期化データの他に、従来 の符号器および復号器の仕様は、必要なタイミング、すなわちスプライスポイン トのパラメータを定めていない。かかる問題は、１つのストリームと別のストリ ームとを関連させるのに利用できるデータがないことによって更に深刻となって いる。例えば２つ以上のストリームからのデータが占有する復号器のバッファの 内容を、直接かつ信頼性高く決定するためのパラメータは全く規定されていない 。従って、連続したデータフローを維持し、バッファがアンダーフローまたはオ ーバーフローとならないように、スプライスすべき２つのストリームの各々から の充分な量のデータを復号器のバッファが含むように保証するための、直接的な サポートはない。 符号化されたデータストリームを共にスプライスすることに関連する上記およ びそれ以外の問題にも係わらず、これまで複数の解決案が提案されており、その うちの２つは既に使用されている。従来の１つの解決案はサブジェクトデータス トリームを復号化し、復号化されたフォームでスプライスを実行し、次に単一デ ータストリームとしてデータストリームを再符号化し、よって符号化されたデー タストリームをスプライスする固有の問題を有効に回避する方法がある。不幸な ことに、リアルタイムでスプライスを実行するのに充分ロバストな符号化および 復号化用ハードウェアは、高価でもある。放送用アプリケーションでは別個のデ ータストリームソースによって各テレビチャンネルが提供され、テレビチャンネ ルの任意のものは同じようなスプライシングを必要とする。従って、多数の符号 器および復号器を交換する必要性が生じやすい。 符号化されたデータストリームをスプライスするための従来から利用されてい る別の方法によれば、新データストリームの開始部に、黒くされ、ミューティン グされたビデオフレーム（リーダーフレーム）を添付する。この方法の利点とし て、リーダーフレームを発生するのに最小量のデータでよいことが挙げられる。 従って、復号器のバッファのオーバーフローは生じない。更にリーダーフレーム はデータストリームペアの正確なスプライシングよりも少ないことから生じる視 覚的アーティファクト、例えば当業者で一般にロールオーバーと称されるような ディスプレイの同期がなくなることをマスクするように働く。更にかかる方法は 、交換費用を不要にするよう、現行の符号器および復号器を使用して実行できる 。不幸なことに、スプライスはトランスペアレントではない。ディスプレイされ たデータストリームが与えられている消費者は、黒色にされたフレームに気が付 く。リーダーフレームは新しいストリームの一部、例えばコマーシャルメッセー ジを 形成するので、３０秒コマーシャルに対して９０万ドル以上の支払いをすること がある広告主にとって放送時間が失われることは特に問題である。（従って、各 フレームは１０００ドル以上のコストとなり得る。） これらの試みにも拘わらず、動画およびテレビ協会により現在提案されている 標準化の努力（テレビのための提案ＳＭＰＥ規格−ＭＰＥＧ−２トランスポート ストリームのためのスプライスポイント）は、ＭＰＥＧ−２仕様への新しい拡張 を有利にするために、現在のスプライス方法を廃棄することを示唆している。こ の提案は、データストリームペアのトランスペアレントな、すなわちシームレス なスプライシングを実行することを特に目的とする、新しい、統合されたプロト コルを示唆している。広義に述べれば、提案された規格は符号化の時点でデータ ストリームにスプライスポイントおよび関連するスプライシング支持情報を直接 組み込むことを配慮するものである。不幸なことに、提案された拡張案では少な くとも現在の符号器を交換しなければならない。この案は問題をより複雑にする ので、提案された規格は批准されていない。従って、潜在的な変更だけでなく、 必ず変えられる解釈、実現、インコンパーティビリティ、所有権のある「別の拡 張案」およびその他の問題が生じやすい。 従って、新しい符号器または復号器を必要とすることなく、かつ認識でき、放 送時間を消費するアーティファクトを生じることなく、デジタル式に符号化され たマルチメディアデータストリームを共にスプライスするための装置および方法 が求められている。更に、従来の符号化／復号化仕様を変更するための条件を必 要としない、かかる装置および方法も求められている。 発明の概要 本発明は、デジタル符号化されたデータストリームを共にシームレスにスプラ イスするためのデータ処理システムに基づくスプライシングシステムを提供する ものである。特に本スプライシングシステムは、従来のスプライシングシステム に起因して生じる出費、視覚的なアーティファクトおよび放送時間の喪失を回避 しながら、現在の符号化／復号化仕様に従い、従来の符号器および復号器を使っ て旧データストリームと別個に符号化された新データストリームとのスプライシ ングを実行する。 従って、本発明の好ましい第１実施例は、より大きいＭＰＥＧ−２データスト リーム処理および放送システム内のライブラリーとして機能するスプライサーを 含む。このスプライサーは更にホストアプリケーションおよびより大きいシステ ムのマルチプレクサと直接的または間接的に通信しながら更に機能する。更に多 重化されたＭＰＥＧ−２データストリームチャンネルとして同時送信するための ホスト処理システム内および／またはその外部に記憶されたデータストリームを 共にスプライスするのに、いくつかのスプライサーを同時に呼び出しできる。 有利なことに、スプライサーは新データストリームのスプライスイン入力にお いてデータストリームを一致させるか、または画像のオープングループ（ＧＯＰ ）を閉じるのに、スプライシング中に復号化を必要とすることなく、データスト リームを調節する。このスプライサーは更にスプライシングに起因し、受信復号 器の入力バッファのオーバーフローおよびアンダーフローを防止するよう、更に 新データストリームを調節する。更に、このスプライサーはスプライシングの完 了時に別のスプライサーの介入を受けることなく、新データストリームの他の部 分を符号化されたものとして受信できるという利点を可能にする。 ホストアプリケーションからのライブラリーコールによって呼び出されると、 好ましいスプライサーは対応するスプライスバッファＮのロケーション、スプラ イスインオンリー、すなわちインサートモード選択、オーディオオプション選択 および内部でスプライスを実行する、所望する旧データストリーム部分に先行す るスプライスバッファフル、すなわちスプライスバッファの数を含むセットアッ プ情報を受信する。その後、スプライサーは旧データストリームデータおよびそ の後にスプライスバッファＮ内に逐次入れられる新データストリームが続くスプ ライスを実行する。 好ましいスプライサーはスプライステーブルを創出し、スプライスバッファＮ 内の各スプライスバッファを分析し、離散的タスクおよび同時に進行しているタ スクを実行する。離散的タスクとしては、スプライステーブルを創出すること、 スプライスアウトポイントおよびスプライスインポイントを見つけること、新デ ータストリームの送信時間を決定すること、および新データストリームの受信と 旧データストリームの最終符号器のバッファの復号化とを一致させることが挙げ られる。進行中のタスクとしては、スプライステーブルにデータストリームのフ レーム情報を挿入すること、更に同時に、後のスプライスデータストリームの符 号化を変えることなく、復号器の入力バッファのオーバーフローを防止するよう 、フレーム情報を使用することも挙げられる。 データストリームの受信を一致させ、オーバーフローを防止し、すなわち訂正 するために、スプライサーは新データストリームの異なる部分を遅延し、加速す る。より詳細には、スプライサーはデータストリームの開始点前にゼロパケット を挿入することにより、データストリームの受信を遅延し、データストリームの 開始点からゼロパケットを削除することにより、データストリームの受信を加速 する。同様に、スプライサーはデータパケット前にゼロパケットを挿入すること により、オーバーフローを生じさせるデータストリームを遅延し、後のデータパ ケットからゼロパケットを削除することにより、（符号化されたタイミングをリ セットするよう）後のデータパケットを加速する。ゼロパケットを加えることは 、ホストアプリケーションに対するリターン命令によって実行され、これにより 追加が実行され、その結果は多重化および送信のためのマルチプレクサへルーテ ィングされる。遅延は繰り返しコピー操作を使ってスプライスバッファＮ内でデ ータパケットをシフトするよう、直接スプライサーによって実行される。 別の好ましい実施例では、新規なビットクロック機構を使用することにより、 データストリーム部分の遅延および加速が実行される。１つの特徴によれば、各 繰り返しコピーゼロパケット削除および各ゼロパケット挿入を離散的に実行する のではなく、現在のデータストリーム部分の処理が完了するまで、ゼロパケット カウントを維持する。第２の特徴では、マルチプレクサの作動レートの何分の１ かに従い伝送するための各データストリーム出力バッファを集合するようにマル チプレクサがセットされる。次にスプライサーは所定のバッファに対するゼロパ ケット追加量または削除量を決定し、これら量をホストアプリケーションに戻す 。次にホストアプリケーションはこれら量をマルチプレクサに戻し、マルチプレ クサはこの量を対応するバッファ用のスケジュールに追加する。有利なことに、 繰り返しコピー操作およびホストアプリケーションの操作が回避されるので、処 理システムのスループットを大幅に増加できる。 次の図面および明細書から本発明の上記およびそれ以外の目的、利点、利益が 明らかとなろう。 図面の簡単な説明 図１は、本発明の好ましい実施例に従ってデジタル式に符号化されたマルチメ ディアデータストリームを受信し、準備し、記憶し、検索し、送信するためのシ ステムを示す、機能的ブロック図である。 図２は、図１に示されたシステムをより詳細に示す機能的ブロック図である。 図３は、本発明に係わる好ましいスプライサーを示す機能的ブロック図である 。 図４は、本発明に係わるデジタル式に符号化された第１ストリームと、デジタ ル式に符号化された第２ストリームを共にスプライスするための好ましいフロー チャートである。 図５は、本発明に係わる、図４の好ましい方法に従って第１データストリーム 内のスプライスアウトポイントを見つけるための好ましい方法を示すフローチャ ートである。 図６は、本発明に係わる、図４の好ましい方法に従って第２データストリーム 内のスプライスインポイントを見つけるための好ましい方法を示すフローチャー トである。 図７は、本発明に係わる、図４の好ましい方法に従って第２データストリーム 内の画像のリーディングオープングループを閉じるための好ましい方法を示すフ ローチャートである。 図８は、図７の好ましい方法に従って画像のグループを閉じる際に時間的基準 を分解するための好ましい方法を示すフローチャートである。 図９Ａは、ＭＰＥＧ−２で符号化されたストリームを復号器の入力バッファに よりこれまでどのように受信し、復号化していたかを示すグラフである。 図９Ｂは、本発明に係わる図４の好ましい方法に従い、連続するビデオフレー ムをディスプレイするための２つのビデオフレーム間の従来のディスプレイ操作 レートのタイミング関係を示す。 図１０は、本発明に係わる図４の好ましい方法に従い、リアルタイムの新デー タストリームＰＣＲを決定するための好ましい方法を示すフローチャートである 。 図１１は、本発明に係わる図４の好ましい方法に従い、リアルタイムの新デー タストリームＰＣＲを決定した後に、第１データストリームに関連し、第２デー タストリームを復号器の入力バッファによってどのように受信するかを示すグラ フである。 図１２は、本発明に係わる図２の好ましい方法に従い、復号器の入力バッファ による第２データストリームの受信と復号器の入力バッファによる第１データス トリームの復号化とを一致させるための好ましい方法を示すフローチャートであ る。 図１３Ａは、本発明によりデータストリームをスプライスバッファ内に記憶す る、データストリーム内のゼロパケットを削除するための好ましい方法を示す。 図１３Ｂは、本発明によりに係わる図１２ａの好ましい方法を実施した後のス プライスバッファのコンフィギュレーションを示す。 図１４は、本発明により復号器の入力バッファ内に旧データストリームと共に スプライスすべき新データストリームとが同時に存在することから生じる、復号 器の入力バッファのオーバーフローを除くための好ましい方法を示すフローチャ ートである。 図１５Ａは、本発明により、復号器の入力バッファのオーバーフローを検出し 、これを除くための好ましい方法に従ってスプライステーブルに旧データストリ ームのフレームデータを挿入するための好ましい方法を示す、第１フローチャー ト部分である。 図１５Ｂは、本発明に係わる図１４の好ましい方法に従い、スプライステーブ ルに新データストリームのデータを挿入し、同時にオーバーフローを検出するた めの好ましい方法の第１部分を示す、図１５Ａに続くフローチャートである。 図１５Ｃは、本発明に係わる図５Ｂに続くフローチャートである。 図１６は、オーバーフローの特性を示し、本発明に係わる図１５ａ〜図１５ｃ の好ましい方法により、オーバーフローを検出し、除去することを更に示すグラ フである。 図１７は、本発明に係わる、図１５ａ〜１５ｃの好ましい方法に係わるスプラ イステーブルの内容例を示す。 図１８は、本発明に係わる第１データストリームのオーディオスプライスアウ トポイントをセットするための好ましい方法を示すフローチャートである。 図１９Ａは、本発明に係わるオーディオスプライスアウトポイントの別の例を 示す。 図１９Ｂは、本発明に係わるオーディオスプライスインポイントの別の例を示 す。 図２０は、本発明に係わる、新データストリーム内にスプライスインポイント をセットするための好ましい方法を示すフローチャートである。 図２１は、本発明の別の好ましい実施例により、ビットクロックを利用する好 ましいスプライサーを示すフローチャートである。 図２２は、本発明に係わるオーバーフロー条件を検出し、訂正するための、図 １５ａ〜１５ｃの好ましい方法の改良を示すフローチャートである。 好ましい実施例の詳細な説明 明瞭にするため、本明細書で説明する実施例はＭＰＥＧ−２仕様に従って符号 化されたり、復号化される、デジタル式に符号化されたデータストリーム（以下 、データストリーム）を共にスプライスすることに、主に関する。より詳細には 、この説明はコマーシャルメッセージを伴って放送される進行中のテレビプログ ラムのリアルタイムのスプライシングに焦点を合わせるものであり、このスプラ イシングは消費者の場所にあるケーブル受信機へ送信するためのケーブル放送局 で実行される。更にこの説明は、デジタル式に符号化されたマルチメディアデー タストリームを受信し、準備し、記憶し、検索し、送信するための好ましいシス テム内に埋め込まれたスプライスアプリケーションプログラムにも関する。 しかしながら、当業者であれば多くのデジタル符号化／復号化仕様が存在して おり、これら仕様は本発明を容易に実施できる（ＭＰＥＧ仕様の他の）仕様にも 導入できることが理解できよう。例として、欧州通信規格があるが、かならずし もこれに限定されるものではない。更に、主題のデータストリームの内容は必ず しもテレビプログラムおよびコマーシャルに限定されるものではない。むしろ、 本明細書に記載の内容はデジタル符号化を利用する広い範囲のオーディオ、ビデ オおよびその他のデータのタイプに適用できる。全体が図１に示されているよう に、本発明により、デジタル式に符号化されたマルチメディアデータストリーム を受信し、準備し、記憶し、検索し、送信するための好ましいシステム１００は 、ホスト処理システム、例えばパソコン、すなわちＰＣ内に全体が収容されてい ることが好ましい。システム１００は入力デバイス１１０と、プロセッサ１１２ と、メモリ１１４と、記憶デバイス１１６と、ＭＰＥＧ−２符号器１２０と、Ｍ ＰＥＧ−２復号器１２５と、衛星Ｉ／Ｏ１３０と、ケーブルＩ／Ｏ１３３と、ネ ットワークＩ／Ｏ１３５と、オーディオＩ／Ｏ１３７と、ビデオＩ／Ｏ１３８と 送信機１３９とを含む、電気的に結合されたハードウェア要素を含むことが好ま しい。システム１００は、オペレーティングシステム１４０と、Ｉ／Ｏハンドラ ー１４５と、ストリームルーター１５０と、バッファ発生器１６０と、スプライ スバッファ１６５と、スプライサー１７０と、マルチプレクサバッファ１８０と 、マルチプレクサ１９０とを含む、結合されたソフトウェア要素を更に含む。 当業者であれば、本発明の範囲内ではシステム１００の要素のいくつかの変形 が彼のうえあることが明らかとなろう。例えば所定のプロセッサおよびコンピュ ータの性能の変形例および進みつつある技術進歩、ハードウェア要素、例えばＭ ＰＥＧ−２符号器１２０およびＭＰＥＧ−２復号器１２５は、ソフトウェアまた はハードウェアとソフトウェアの組み合わせで具現化できる。同様に、ソフトウ ェア要素、例えばマルチプレクサ１８５をハードウェアまたはハードウェアとソ フトウェアの組み合わせで具現化してもよい。更に、他の計算デバイスへの接続 はネットワークＩ／Ｏ１４５としてしか示されていないが、他の計算デバイス（ ローカルエリアネットワーク、ワイドエリアネットワークおよびインターネット を含むが、これらに限定されているわけではない）への有線、無線、モデムおよ び／または他の接続も利用できる。別の例としては分散処理、マルチサイトヴュ ーイング、情報転送、コラボレーション、リモート情報検索およびマージングな らびに関連する機能の各々を使用することも可能であることが挙げられる。種種 のオペレーティングシステムおよびデータ処理システムも利用できるが、少なく ともＩＢＭ（インターナショナルビジネスマシン社の商標）コンパーチブルなコ ンピュータ、またはＵＮＩＸをベースとするオペレーティングシステムで作動す るコンピュータ上で作動する従来のマルチタスクオペレーティングシステム、 例えばウィンドウズ９５またはウィンドウズＮＴ（マイクロソフト社の商標）が 好ましく、以下、本発明の説明ではこれらを想定する。入力デバイス１１０は、 コマンドおよび／またはデータを入力するための、任意の数のデバイスおよび／ またはデバイスタイプを含むことができ、これらデバイスにはキーボード、マウ スおよび／または音声認識が含まれるが、これらに限定されるものではない。 図２のブロック図は、本発明に係わるスプライサーが、好ましくは図１のシス テム１００内のサポートアプリケーションとしてどのように好ましく作動するか を、機能的により詳細に示す。広義に説明すると、システム１００は外部ソース および／または記憶デバイスからデータストリームを受け、必要に応じてデータ ストリームに対するＭＰＥＧ−２の符号化を実行し、符号化されたデータストリ ームを多重化し、次に（従来の復号化により、または従来の復号化を用いること なく）、多重化されたデータストリームを記憶するよう、ユーザーの選択に従っ て作動することが好ましい。スプライシングが選択されると、システム１００は 好ましくは現在送信されている（旧）データストリームおよび新データストリー ムをスプライサーへルーティングする。スプライサーは新データストリームが多 重化されたデータストリームに加えられる場合、新データストリームが旧データ ストリームのシームレスな追加された連続ストリームとして復号器によって受信 され、復号化され、提示されるよう、必要に応じてリアルタイムでデータストリ ームペアを変更することが好ましい。 より詳細には、ユーザーが情報を入力し、Ｉ／Ｏハンドラー１４５のユーザー インターフェース１４５ａと共に、入力デバイス１１０、オーディオＩ／Ｏ１３ ７およびビデオＩ／Ｏ１３８を使って、従来どおり情報を入力し、出力を受信す ることが好ましい。更に、ウィンドウズのオペレーティングシステムの仕様およ びプラクティスに従って、従来どおりユーザーインターフェース１４５ａが更に 設けられることが好ましい。ユーザーはユーザーインターフェース１４５ａを通 してＩ／Ｏインターフェース２０３において利用できる（すなわち受信された） データストリームソースから多数のデータストリームソースおよび／または記憶 デバイス１１６から検索されたデータストリームを選択できる。Ｉ／Ｏインター フェース１０３は衛星インターフェース１３０およびケーブルインターフェース １３３（すなわち衛星およびケーブルを介してそれぞれ送信された、データスト リームを取り扱うためのトランシーバー拡張カードおよび／または埋め込み型ハ ードウェアおよび／またはソフトウェア）、ネットワークインターフェース１３ ５、オーディオインターフェース１３７およびビデオインターフェース１３９を 含む。当業者であれば、デフォルト値および／または時限および／または発生に よって駆動されるスケジュール化された選択に従って、ユーザーによりデータス トリームソースおよびその他のオプションを相互対話式に選択できることが理解 できよう。 通常のシステム１００の動作中、（すなわちスプライシングがない時には）ス トリームルーター１５０はデータストリームのタイプに従って選択されたデータ ストリームをルーティングする。より詳細には、ストリームルーターは既に符号 化されたデータストリームソースをＩ／Ｏインターフェース１３０からバッファ 発生器１６０へルーティングする。ストリームルーター１５０は更に符号化され ていないデータストリーム、例えば記憶デバイス１１６からのデータストリーム を（符号器１ ２２０および符号器Ｎ １２０が例示するような）それぞれの符 号器を通してバッファ発生器１６０へルーティングする。バッファ発生器１６０ は開始されたデータストリームの受信時に出力バッファを創出する。簡潔にする ため、通常の動作中にバッファ発生器１６０によって創出された出力バッファを 、本明細書では（マルチプレクサバッファ１ ２８０が例示するような）マルチ プレクサバッファと称す。マルチプレクサバッファが創出されると、その後、バ ッファ発生器１６０は対応するＩ／Ｏインターフェースから受信されたデータを マルチプレクサバッファへ挿入し、更にマルチプレクサバッファが満杯となった 時、およびＭＰＥＧ−２の仕様によるタイミングの検討に従って、データレディ フラグをセットする。ユーザーはそれぞれの各マルチプレクサバッファのサイズ を選択的に決定できるが、１つのマルチプレクサバッファのサイズは、一般に約 ６４キロバイトから４７×６４キロバイトの範囲であるので、少なくとも３００ 個のパケットを提供できる。 スプライス動作が選択されると、ストリームルーター１５０もデータストリー ムのタイプに従って選択された新旧データストリームをルーティングする。より 詳細には、ストリームルーター１５０は（再び一般的にはＩ／Ｏインターフェー ス２０３からの）符号化されたデータストリームを直接バッファ発生器１６０へ ルーティングし、（再び一般には記憶デバイス１１６、オーディオＩ／Ｏ１３７ およびビデオＩ／Ｏ１３８からの）符号化されていないデータストリームを、利 用可能な符号器（すなわち符号器１ ２２０から符号器Ｎ １２０）を通し、通 常の動作と同じようにバッファ発生器１６０へルーティングする。バッファ発生 器は更に通常の動作と同じように出力バッファを創出する。しかしながら簡潔に するため、スプライシング動作中にバッファ発生器１６０によって創出される出 力バッファを（例示されたスプライスバッファ、スプライスバッファＮ ２６５ およびスプライスバッファ１ ２６５ａが示すような）スプライスバッファと称 す。スプライスバッファを創出した場合、バッファ発生器１６０はその後、スプ ライスバッファにデータストリームのデータを挿入し、（例示したスプライサー 、すなわちスプライサーＮ ２７０およびスプライサー１ ２７０ａが示すよう な）スプライサーをスタートさせる。スプライサーはホストアプリケーションプ ログラムのうちのバッファ発生器のアプリケーション部分からのライブラリーコ ールによってスタートされたＣ＋ライブラリーであることが好ましい。このスタ ートされたスプライサーはスプライスを実行し、値をホストアプリケーションへ 戻す。次にホストアプリケーションはステータスレディフラグを設定する前に、 スプライスバッファ内のデータを更に操作することができる。従って、広義に述 べれば、スプライサーＮ ２７０をコールすることが好ましく、このスプライサ ーは（スプライスバッファＮ ２６５内に、一度に１つのバッファフルで含まれ る）新旧データストリームペアからのデータストリームのデータを分析するよう 作動し、スプライスを実行し、次にホストアプリケーションへパラメータを戻す 。ホストアプリケーションはバッファがマルチプレクサ１９０によって受信され る、約０．５〜１秒前に、ホストアプリケーションがスプライスバッファＮ ２ ６５を満たし、よってバッファ内に含まれるデータに作用するのに、少なくとも ０．５秒をスプライサーＮ ２７０に与えることに留意すべきである。通常の動 作およびスプライシング動作の間、出力バッファの各々に対し、マルチプレクサ １９０は連続してデータレディフラグ検査を通過するようにサイクル動作し、レ ディ ステートを検出すると、それぞれのバッファの内容を送信機１３９へ転送する。 送信機１３９はマルチプレクサバッファの内容を受信すると、出力されたバッフ ァの内容を送信し、および／または（ユーザーの選択に従ってオプションで）マ ルチプレクサバッファの内容をストリームルーター１５０へルーティングする。 ストリームルーター１５０は送信機１３９からのデータを受信すると、受信した データを復号器１２５、Ｉ／Ｏインターフェース１０３および／または記憶デバ イス１１６へルーティングする。 システム１００によって送信された多重化データストリームを、（再放送局２ ９１が例示するような）１つ以上の再放送局によって受信し、再送信したり、（ 受信機２９３および２９５が例示するような）消費者の受信機によって直接受信 することができる。多重化されたデータストリームに含まれるコンポーネントデ ータストリームの各々は、ＭＰＥＧ−２仕様に従って別個のテレビチャンネルの ためのデータソースとして受信される。スプライスされたデータストリームペア （例えばコマーシャルによってスプライスされた進行中のテレビプログラム）も 受信され、単一のＭＰＥＧ−２の符号化されたチャンネルとして実質的にトラン スペアレントにスプライスされる。 現在ではシステムは各データストリームペアをスプライスするのに、約５ＭＨ ｚの平均バンド幅を必要とする。従って、例えば２００ＭＨｚのペンティアム（ インテル社の商標）プロセッサを有する従来のＰＣは、４０個までのデータスト リームを同時にサポートできる。しかしながら、プロセッサ、バックプレーン、 メモリ、記憶デバイスおよびシステムのソフトウェアの進行する改良だけでなく 、更なる可能性のあるシステム１００の最適化を考慮すれば、更にスループット が増加する可能性がある。システム１００は更に適当な同期化ソースを設けるこ とにより、更に増加した数のデータストリームを処理するよう、他のシステムと 更に同期化できる。 特にＭＰＥＧ−２仕様によってカバーされていない条件に関連し、特定の受信 機のハードウェア／ソフトウェアコンフィギュレーションおよび機能性は大幅に 変わり得る。しかしながら、各受信機は復号化のための完全なハードウェアおよ び／またはソフトウェアシステムを含む。送信信号は多重化されたデータ信号と して受信されるので、各受信機はデマルチプレクサ（図示せず）を含む。各デー タストリームは多重化されたビデオおよびオーディオデータを更に含むので、各 受信機はサポートされた数のデータストリームチャンネルの各々に対し、コンポ ーネントデータストリームのオーディオービデオデマルチプレクシング機能（図 示せず）を更に含む。各受信機はＭＰＥＧ−２で符号化されたオーディオおよび ビデオデータを復号化するための復号器を各チャンネルに対しても含む。例えば ビデオ復号器２９３ａおよびオーディオ復号器２９３ｂは、単一のＭＰＥＧ−２ の符号化されたデータストリームのための、かかる必要な復号器のペアを示す。 （各バッファのサイズ、または別に表現すれば各バッファが含むデータ量は受信 機ごとに異なることがある。）各復号器は復号化前にそれぞれの多重分離された ビデオまたはオーディオデータを受信するための入力バッファ（図示せず）と、 復号化されたビデオまたはオーディオデータを受信し、オーディオ−ビデオ表示 を再構成する（すなわちビデオおよび他のデバイスへ出力するための再構成）た めの対応するフレームバッファとを含む。 図３および４は、図２を参照しながら本発明に係わる好ましいスプライサおよ びスプライシング方法を一般に示す。簡潔にするため、次の説明は、処理のため のシステム１００に対しては２つのデータストリーム（新旧データストリーム） しか与えられないと見なす。従って、スプライサー、スプライサーＮ ２７０（ 図２）および１つの出力バッファ、スプライスバッファＮ ２６５についてしか 説明しないことにする。当業者であれば、本明細書に記載の説明を鑑みれば、別 の出力バッファとスプライサーの組み合わせは同じように好ましく作動すると理 解できよう。 図３のブロック図に示されるように、スプライサーＮ ２７０は好ましくはス プライスエンジン３１０、シーケンスファインダー３２０、フレームファインダ ー３３０およびパケットフィルタ３４０、ＧＯＰファインダー３５０、パケット シフター３６０およびフレームテーブル３７０を含む結合要素を含むことが好ま しい。広義に述べれば、スプライスエンジン３１０は好ましくはフレームテーブ ル２７０を創出し、これにデータを入れ、他のスプライサーＮ ２７０の要素の 演算を利用するものである。シーケンスファインダー３２０、フレームファイン ダー３３０、パケットファインダー３４０およびＧＯＰファインダー３５０は、 ＭＰＥＧ−２で符号化されたデータストリームからそれぞれシーケンス、フレー ム、パケットおよびＧＯＰデータを検索する。パケットシフター３６０は、シー ムレススプライスのスプライサーＮ ２７０を使って創出するためのタイミング の不一致を解決することが好ましい。バッファのオーバーフロー状態を決定する ためにフレームテーブル３７０を使用することが好ましい。 図４のフローチャートは図２および３を参照して本発明に係わる好ましいスプ ライス方法を示す。上記のように、ホストアプリケーションからの呼び出しによ ってスプライシングを開始することが好ましい。ホストアプリケーションが満た すスプライスバッファＮ ２６５に比例したホストアプリケーションからの呼び 出しは、スプライサーＮ ２７０を開始（すなわち立ち上げ、呼び出し、例示） する。この呼び出しは更にホスト処理システム内のスプライスバッファＮ ２６ ５のロケーション（または外部である場合はスプライスバッファの外部ロケーシ ョン）を含み、ホストアプリケーションが所定の回数でスプライスバッファＮ ２６５を満たした時に、スプライスを実行すべきことを表示する。言い換えれば 、ホストアプリケーションによりスプライサーＮ ２７０へ送られるバッファロ ケーションパラメータはバッファロケーションを示すが、スプライサーＮ ２７ ０へ送られる別のパラメータはスプライサーＮ ２７０が旧データストリームを 終了させる「スプライスバッファフル」を示す。ホストアプリケーションは更に 、旧データストリームの最終スプライスバッファフルをスプライスバッファＮ ２６５へ送る際に、スプライスバッファＮ ２６５を新データストリームのスプ ライスバッファフルで満たし始める。スプライスバッファＮ ２６５のサイズお よびスプライシングの開始は、ユーザーが選択可能であることが好ましいが、バ ッファＮ ２６５は一般に約３００キロバイトのデータを収容でき、バッファの スタート後、約５０ミリ秒でスプライシングが開始する。 当業者が本明細書の内容を検討すれば、スプライサーＮ ２７０と別個の処理 システムにより更にデータストリームソースおよび／またはホストアプリケーシ ョンを処理でき、および／またはスプライサーＮ ２７０をライブラリーでない スタンドアローンのプロセスまたはサブプロセスとして実現できることが理解で きよう。しかしながら、スプライスをリアルタイムで完了するための、データを 取り扱う条件がロバストでなければならないので、１つの処理システム内に完全 に統合し、ライブラリーを使用することが好ましい。しかしながら、ライブラリ ーを用いる場合、多数の同時スプライシング動作を配慮するように、多数のかか るプロセスまたはサブプロセスをサポートすることが好ましい。説明が進むにつ れより明らかとなるように、ホストアプリケーションにより創出され、満たされ 、スプライサーが必要とするように変更される単一のスプライスバッファは、ロ バストな動作をする必要性があるために同じように利用される。例えば、多数の バッファ（すなわち多数のロケーションポインタおよび隣接していないデータロ ケーション）の管理および（例えば多数のスプライサー入力バッファから別個の スプライサー出力バッファへの）バッファのコピーを回避することは、スプライ シングを実行するための処理システムのスループット条件を最小にすることを助 ける。 図示するように、工程４０５ではスプライサーＮ ２７０が発生し、フレーム テーブル３７０（図３）にデータを挿入し始める。ステップ４１０では、スプラ イサーＮ ２７０はスプライスの前で旧データストリームの送信を終了する旧デ ータストリーム内のデータロケーション（以下、旧データストリームのスプライ スアウトポイントまたは単にスプライスアウトポイントと称す）を探す。ステッ プ４２０では、スプライサーＮ ２７０は新データストリームの送信を開始する 、新データストリーム内のデータロケーション（以下、新データストリームのス プライスインポイントまたは単にスプライスインポイントと称す）を探す。ステ ップ４３０で、スプライサーＮ ２７０は新データストリームの送信を開始すべ き時間（以下、リアルタイムの送信開始ポイントと称す）を決定し、ステップ４ ４０でスプライサーＮ ２７０は最終の旧ストリームバッファの復号化を開始す るのと同時に、受信機の復号器によって新データストリームを受信するのが好ま しいように、新データストリームを整合し、ステップ４５０でスプライサーＮ ２７０は復号器のバッファのオーバーフロー状態を検出し、訂正する。 スプライシングの完了後、スプライサーＮ ２７０は呼び出しアプリケーショ ンへパラメータを戻すことが好ましい（すなわち呼び出しアプリケーションのバ ッファ発生器のサブプロセス）。この呼び出しアプリケーションは更にスプライ スバッファＮ ２６５の内容を操作でき、次に既に述べたように、データレディ フラグをセットする。その後、スプライサーＮ ２７０はＰＣＲ不連続パケット をセットできる。 次の説明から明らかとなるようにスプライサーＮ ２７０は送信後、オーバー フロー状態が発生しないよう、スプライシング全体にわたってフレームテーブル ３７０を使用し、送信に先立つ潜在的な復号器の入力バッファのオーバーフロー 状態の発生を検出し、これを除く。バッファ発生器１６０（図２）が旧データス トリーム、次に新データストリームからの対応するデータの別のバッファフルで スプライスバッファ２６５を満たし続ける際に、スプライサー２７０は同時にス テップ４１０〜４５０も実行する。例えばスプライサーＮ ２７０は旧データス トリームのスプライスアウトポイントを探すが、他方、スプライスバッファＮ ２６５は旧データストリームの最終部分を含む。スプライサーＮ ２７０は、ス プライスバッファＮ ２６５が新データストリームの第１部分を含む際に、新デ ータストリームのスプライスインポイントを探し、次々に同様のことを行う。説 明を簡潔にするため、復号器の入力バッファのオーバーフローの検出および除去 （ステップ４５０）に関連する、対応する説明のために、フレームテーブル３７ ０の創出および挿入については保留する。更に説明を簡潔にするため、オーディ オスプライシングを行うことだけに注目しながら、好ましいビデオスプライシン グについてまず検討する。次にオーディオスプライシングについて別個に説明す る。 図５は、旧データストリームの最終スプライスバッファフルを受信した際に、 好ましいスプライサーＮ ２７０がどのようにして旧データストリームのビデオ スプライスアウトポイントを探すかを示す。図示するように、スプライサーＮ ２７０は多数の作動モードを提供することが好ましく、このモードのうちの各々 は呼び出しアプリケーションによって特定できる。挿入作動モードでは、スプラ イサーＮ ２７０は、例えば進行中のプログラム（例えば映画）内にコマーシャ ルメッセージを挿入すべき場合、旧データストリームに後のスプライスが先行す るように、スプライスを実行する。映画はコマーシャルメッセージの後に上映が 続くので、映画のデータストリームの送信を中断する好ましいポイントは、不連 続ポイント、すなわちスプライスアウトポイントの直後に、後に映画の送信を再 開するのを容易にするポイントとなる。これと対照的に、スプライスオンリーモ ードでは、スプライサーＮ ２７０は旧データストリームを後に連続させる問題 を生じることなく、アイソレートされたスプライスを実行する。かかるスプライ スオンリーモードは、別個に符号化されたプリ録画された映画の終了時またはラ イブの放送中のような状況で一般に選択されるので、ユーザーは（エクストラフ レーム前の）早期スプライスポイントを探すことが特に望ましくなるように、ビ デオデータのエクストラフレームを含むようなライブ放送の最終スプライスバッ ファフルを選択してもよい。 図示されるようにステップ５１０で挿入モードが選択されている場合、スプラ イサーＮ ２７０はステップ５２０でシーケンスヘッダーの開始前に旧データス トリームのスプライスアウトポイントを探す。この代わりに、ステップ５１０で スプライスオンリーモードが選択されている場合、スプライサーＮ ２７０はス テップ５３０でシーケンスヘッダー、ＧＯＰヘッダー、ＩフレームまたはＰフレ ームが最初に発生する直前の、旧データストリームのスプライスアウトポイント を探す。次にステップ５４０で、スプライサーＮ ２７０はスプライスポイント に先行するバイトとして、送信のためのスプライスバッファＮ ２６５内のバイ トをセットする。後に説明するように、スプライサーＮ ２７０は旧データスト リームのオーディオスプライスアウトポイント（図示せず）を探すのに、旧デー タストリームのビデオスプライスアウトポイントを使用する。 スプライサーＮ ２７０は作動的には、シーケンスファインダー３２０、ＧＯ Ｐファインダー３５０またはフレームファインダー３３０を含むデータタイプの ファインダーのそれぞれを使って（最初に受信されたデータでスタートする）ス プライスバッファＮ ２６５に含まれるデータを分析することにより、シーケン スヘッダー、ＧＯＰヘッダー、ＩフレームまたはＰフレームを探すことが好まし い。各データタイプのファインダーは、後により詳細に説明するように、ＭＰＥ Ｇ−２の仕様に従ってそれぞれのデータタイプを探すためのステートマシンを含 む。スプライサーＮ ２７０は（サーチ中の）スプライスポイントに先立ち、ス プライスバッファＮ ２６５内に含まれるデータバイト数をカウントし、ホスト アプリケーションがマルチプレクサへ送るべきスプライスバッファＮ ２６５内 のデータバイトの数として、このデータバイトの数をホストアプリケーションへ 戻すことにより、送信のためのバイトを更にセットする。ホストアプリケーショ ンはこの情報を受け取った時に、スプライスバッファ２６５内の（スプライスポ イント後の）残りのバイトを一般に無視する。 図６〜８は、図３を参照しながら、好ましいスプライサーが新データストリー ム内のビデオスプライスインポイントをどのように探すかを示す。説明するよう に、ホストアプリケーションは（スプライサーＮ ２７０の呼び出し時に）旧デ ータストリームの終了部分を含むスプライスバッファフルを示す。従って、次の スプライスバッファフルを示す。従って、その後のスプライスバッファフルは、 新データストリームデータの第１部分を含む。広義に説明すれば、スプライサー Ｎ２７０は新データストリームのスプライスポイントを決定するよう、スプライ スバッファＮ ２６５内に含まれるデータストリームのデータを再び分析する。 まず、ＭＰＥＧ−２仕様の所定の特徴を参照することによって、スプライサーＮ ２７０の作動の細部についてより容易に理解できよう。 ＭＰＥＧ−２仕様は連続するビデオストリームを一連のシーケンスとして符号 化することを配慮したものである。各シーケンスは更に画像のグループ（ＧＯＰ ）に分割され、各ＧＯＰは一連の符号化されたビデオフレームを含む。各シーケ ンスはシーケンスヘッダーを含み、各ＧＯＰはＧＯＰヘッダーを含み、各フレー ムはフレームヘッダーを含む。更に説明するように、各シーケンスは少なくとも １０のプログラムクロック基準、すなわちＰＣＲを含む。更に、各データストリ ームは隣接するが、必ずしも連続しない一連のパケットとして送信され、各パケ ットはパケットヘッダーを有する。各ＭＰＥＧ−２で符号化されたビデオフレー ムは、ビデオデータおよびフレームタイプのフィールド（すなわちＩ、Ｂまたは Ｐフレーム）の他に、タイミングおよび相対的順序情報を更に含む。フレームタ イミング情報は（フレームごとに）復号化時間スタンプ、すなわち（受信したフ レームを復号化する時間を示す）ＤＴＳフィールドと、対応するプレゼンテーシ ョン時間スタンプ、すなわち（復号化されたフレームをディスプレイに与える 時間を示す）ＰＴＳフィールドとを含む。フレーム相対順序情報は（フレームご とに）（同じＧＯＰ内の他のフレームと比較してフレームをディスプレイすべき 順序を示す）時間基準フィールドを含む。 しかしながら、データストリーム内に含まれる多量の識別情報にも拘わらず、 ＭＰＥＧ−２の符号化は、多くは容易にアクセスできない態様で、単一の符号化 されたデータストリームに関する情報しか与えない。例えばＭＰＥＧ−２仕様は 上記情報の可変順序およびＧＯＰ間、およびパケット間のかかる情報の分布を配 慮したものである。特にデータストリーム内では第１シーケンスヘッダーの次に （第１ＧＯＰに対する）ＧＯＰヘッダーが続かなければならず、次にフレームヘ ッダーの前のほぼ任意の場所に（ＧＯＰに含まれる最初のフレームのための）フ レームヘッダー、ＤＴＳおよび最初のフレームのためのＰＴＳペアが位置できる 。後に明らかとなるように、スプライスポイントを探し、新データストリームと 旧データストリームとのリアルタイムの整合を助ける双方のために、スプライサ ーＮ ２７０によりこのＤＴＳとＰＴＳペアとを使用することが好ましい。 次に図６を参照すると、スプライサーＮ ２７０は新データストリームの第１ ビデオフレームのために、まずＤＴＳおよびＰＴＳを探すことにより、スプライ スを実行することが好ましい。スプライサーＮ ２７０はステップ６１０で新ス トリームの第１シーケンスヘッダーをまず探し、次にステップ６２０で（第１ビ デオフレームに対するフレームヘッダーとなる）第１フレームヘッダー前の最終 ＤＴＳを探し、記憶し、次にステップ６３０内のＤＴＳに対応するＰＴＳを探し 、記憶することにより、このＤＴＳとＰＴＳペアを探す。次にステップ６４０で 、スプライサーＮ ２７０は新ストリームの最初に提示されたフレームがＩフレ ームとなることを保証する。より詳細には、新データストリームの新ＧＯＰがオ ープンである場合、スプライサーＮ ２７０はＧＯＰを閉じる。最後に、ステッ プ６５０で、スプライサーＮ ２７０はオーディオスプライスインポイントを探 す。（説明を簡潔にするため、ビデオに関連する説明を完了した後に、オーディ オスプライスインおよびスプライスアウトについて説明する。） スプライサーＮ ２７０はシーケンスファインダー３２０（図３）をスタート させることにより作動的にシーケンスヘッダーを探すことが好ましい（ステップ ６１０）。シーケンスファインダー３２０はシーケンスヘッダー符号の最初の発 生に対し、スプライスバッファＮ ２６５に含まれる新データストリームのデー タを分析するステートマシンであることが好ましい。各シーケンスヘッダー符号 は数列「０００００１Ｂ３（１６進）」としてＭＰＥＧ−２仕様によって定義さ れる。同様に、スプライシングエンジンは先のＤＴＳおよびＰＴＳ（すなわち新 データストリームの第１フレームに対するＤＴＳおよびＰＴＳ）に対する新デー タストリームのデータを分析する。当業者が本発明の内容を検討すれば、スプラ イスインポイントは新データストリームの第１フレーム以外のフレームとして別 個に選択できることが理解できよう。例えば完全なコマーシャルメッセージのう ちの後方部分だけを再生したい場合、かかる別のフレームが必要となり得る。か かる場合、ユーザーは望ましいグロススタート時間（この時間からスプライサー Ｎ ２７０は更にスプライスインポイントを決定する）を指定するか、またはュ ーザーはスプライスインポイントを直接指定できる。 図７および８はスプライサーＮ ２７０が新データストリームの第１オープン ＧＯＰを好ましくどのように閉じるかを示す（図６のうちのステップ５４０）。 符号化仕様、特にＭＰＥＧ−２はビデオ画像またはフレーム（すなわちＩフレ ーム）を再創出するように、自ら十分なデータを含むフレームで各ＧＯＰを開始 すべきことを一般に求めない。ビデオ画像を再創出するために、先行するＧＯＰ からのフレームを必要とする第１フレームを有するＧＯＰは、一般にオープンＧ ＯＰと称される。例えば新データストリームを編集し、スプライシング前に記憶 した場合（ブロークンリンク）、オープンＧＯＰが発生し得る。適当な符号化を 仮定すると、オープンＧＯＰには常に対応するＩフレームを含むＧＯＰが先行し 、よってオープンＧＯＰの従属したフレームを再創出できるが、新データストリ ームの第１ＧＯＰに関連し、かかるＩフレームは存在しない。従って、スプライ サーＮ ２７０は新データストリームの最初に提示されたフレームがＩフレーム となることを保証する。 オープンＧＯＰを閉じるための、スプライサーＮ ２７０が利用する方法では 、オープンＧＯＰの第１フレームが依存するフレームおよびその第１フレーム自 身を復号化することを行う。次に第１フレームはＩフレームとして再符号化され る。 不幸なことに、かかる方法はリアルタイムのプロセッサに基づくシステムでは専 用ハードウェアを増設すること、および／または必要なスループットの点で高価 である。従って、ＧＯＰを閉じるためのこの別の方法は、絶対的な精度が望まれ るアプリケーションに合わせたオプションとしてしか提供されない。 しかしながら、先のオープンＧＯＰ内の残りのフレームを更に最小限だけ変更 しながら、従属するリーディングフレーム（すなわちＢフレーム）を再構成する のではなく、これを削除することにより、オープンＧＯＰを別の方法で閉じるこ とができることが判っている。削除されたビデオフレームによって示される画像 が失われ、新データストリームの長さが影響されるが、ＧＯＰを閉じるのに必要 な最小処理時間を考慮すれば、一般に６６ミリ秒の喪失が許容できることが判っ ている。（図６および７に示されるような、この好ましい方法によれば、新デー タストリームのうちの前方のオープンＧＯＰ以外のすべてのＧＯＰは無変更のま まである。） 次に図７を参照すると、ステップ６１０において、新データストリームの第１ ＧＯＰがオープンＧＯＰである（すなわちＧＯＰの第１フレームはＩフレーム以 外のフレームである）場合、ステップ７２０において、まずスプライサーＮ ２ ７０はすべてのリーディング非Ｉフレームを削除する。次に、ステップ７３０で スプライサーＮ ２７０はＧＯＰ内の他のフレームの各々に対する時間基準を訂 正し、最後にスプライサーＮ ２７０はステップ７４０でＧＯＰの第１Ｉフレー ムのうちのＤＴＳをステップ６２０内で削除されたフレームのうちの最大ＤＴＳ に置換する。 図８のフローチャートは更に、本発明により時間基準をどのように置換するの が好ましいかを示す。図示されるように、ステップ８１０で最後の削除されたフ レームの後で、ＧＯＰ内により多数のフレームが残っている場合、スプライサー Ｎ ２７０はステップ８２０で（現在のフレームを示す）ＧＯＰ内の次のフレー ムヘッダーをまず探す。次にスプライサーＮ ２７０はステップ８３０で現在の フレームに対する対応する時間的基準を探す。最後にスプライサーＮ ２７０は ステップ８４０内で時間基準から削除したフレーム数を引いた値に置換し、次に ステップ７１０へリターンする。 作動上、スプライサーＮ ２７０（図３）は、フレームファインダー３３０を 開始することにより、次のフレームを探すことが好ましい。フレームファインダ ー３３０は、フレームヘッダーの次の発生に対し、スプライスバッファＮ ２６ ５に含まれる新データストリームのデータを分析するステートマシンであること が好ましい。各フレームヘッダーはＭＰＥＧ−２仕様によって数列「０００００ １００（１６進）」として定められる。 例えば図７および８に示される好ましい方法に従って、次のオープンＧＯＰが 閉じられる。 時間基準： ２ ０ １ ５ ３ ４ フレームタイプ： Ｉ Ｂ Ｂ Ｐ Ｂ Ｂ ＤＴＳ： −１ ０ １ ２ ３ ４ まず、２つのリーディングＢフレーム（すなわち時間基準番号０および１）を 削除し、ＩフレームおよびＧＯＰ内でＩフレームに続く２つのＢフレームを残す 。 時間基準： ２ ５ ３ ４ フレームタイプ： Ｉ Ｐ Ｂ Ｂ ＤＴＳ： −１ ２ ３ ４ 次に、最初に削除されたフレームに対する時間基準で開始しながら、他のフレ ームに対する時間基準を逐次置換する。 時間基準： ０ ３ １ ２ フレームタイプ： Ｉ Ｐ Ｂ Ｂ ＤＴＳ： −３ ０ １ ２ 最後に、リーディングＩフレームのうちのＤＴＳを削除されたフレームのうち の最大のＤＴＳに置換する。 時間基準： ０ ３ １ ２ フレームタイプ： Ｉ Ｐ Ｂ Ｂ ＤＴＳ： −１ ０ １ ２ 図９ａ〜図１０は、スプライスインポイントを探した後に、本発明に係わる好 ましいスプライサーが、好ましくは新しいデータストリームに対する新ストリー ムのリアルタイムの送信スタート時間をどのように探すかを示す（すなわち図４ のステップ４２０）。所定の観察されたＭＰＥＧ−２仕様のダイナミックスを簡 単に検討することは、本発明の好ましい実施例に従ってシームレススプライスを どのように提供するかを良好に理解する上で役に立つはずである。 図９ＡのグラフはＭＰＥＧ−２仕様が考えた状況下（すなわちスプライシング がない場合）で、例えば消費者の受信機によってＭＰＥＧ−２で符号化された新 データストリームがどのように受信され、復号化されるかを示す。このグラフは 時間に対する増加する垂直位置として、復号器の入力バッファによって受信され る、ある量のデータを示し、垂直位置は水平軸に沿って左から右へ増加する。傾 斜した曲線の線分９１０〜９１０ｄが示す時間中、データは復号器の入力バッフ ァによって受信されるが、垂直直線線分９２０〜９２０ｄによって示される時間 に復号化が行われる。 図示されるようにｔ１における新データストリームの最初の受信からｔ４にお ける（フレームのＤＴＳに従った）第１フレームの復号化までの間に遅延がある 。ｔ２における第１フレームの受信から（フレームＤＴＳに従った）第１フレー ムの復号化までの遅延は、最初のフレーム（および各連続するフレーム）内のデ ータフィールドによって示されるが、データストリームの受信から第１フレーム の符号化までの実際の時間は、時間ｔ１〜ｔ２およびｔ３〜ｔ４までの初期シー ケンスヘッダーのそれぞれの受信および復号化も含む。 図９Ｂはロールオーバーと一般に称されるビデオアーティファクトを発生する ことなく、動画ビデオをディスプレイするには、１つのビデオフレームに対する 走査時間に等しい、第１フレームに対するディスプレイの開始から次のフレーム に対するディスプレイの開始までの間で、一定の既知の遅延が生じなければなら ないことを更に示している。例えばＮＴＳＣの符号化ではフレーム間遅延時間は 約３３ミリ秒である。従って、送信から復号化までの遅延時間（従って受信から 復号化までの遅延時間）を考慮し、フレーム間ディスプレイ遅延時間に比例した 新ストリームのディスプレイを保証する信頼できるタイミング基準を設けること によって、シームレススプライスを得ることができることが判っている。 図１０のフローチャートは、好ましいスプライサーが新データストリームのリ アルタイムの送信開始時間をどのにように決定するかを示している（図４のステ ップ４２０）。広義に説明すれば、ステップ１０１０および１０２０は、新スト リームノミに関連する値を発生するが、ステップ１０３０〜１０５０は旧データ ストリームに対応する新データストリームの送信時間を設定するのにこれら値を 利用する。より詳細に説明すれば、ステップ１０１０でスプライサーＮ ２７０ は新データストリームの新パケットに対するＰＣＲ（ＰＣＲ（ｎｅｗ））を検索 し、ステップ１０２０でスプライサーＮ ２７０は次の式が示すような新データ ストリームの第１シーケンスヘッダーに対する送信時間から（初期に記憶されて いた）新ストリームの第１フレームの復号化時間スタンプ（ＤＴＳ（ｎｅｗ）） までの時間差（ｄｅｌｔａ（ｎｅｗ））を計算する。 ｄｅｌｔａ（ｎｅｗ））＝ＤＴＳ（ｎｅｗ）−ＰＣＲ（ｎｅｗ） ステップ１０３０ではスプライサーＮ ２７０は旧データストリームのうちの 最終フレームの復号化時間スタンプ（ＤＴＳ（ｏｌｄ））に対しスプライスバッ ファＮ ２６５内に含まれる旧データストリームのデータを分析する。ステップ １０４０では、スプライサーＮ ２７０は新データストリームに対する連続ディ スプレイ復号化時間スタンプ（ＤＴＳ（ｃｏｎｔｉｎｕｏｕｓ））をステップ１ ０３０内で見つかったＤＴＳ（ｏｌｄ）と（以下の説明でギャップとも称す）フ レーム間遅延時間との和として計算する。 ＤＴＳ（ｃｏｎｔｉｎｕｏｕｓ）＝ＤＴＳ（ｏｌｄ）＋フレーム間遅延時間 ＮＴＳＣの場合、この式は次のようになる。 ＤＴＳ（ｃｏｎｔｉｎｕｏｕｓ）＝ＤＴＳ（ｏｌｄ）＋１００１／３０，００ ０秒 最後に、ステップ１０５０で、スプライサーＮ ２７０はステップ１０４０で 決定された連続ディスプレイＤＴＳとステップ１０２０で見つけられた送信遅延 時間、すなわちデルタとしてリアルタイミウの新ストリームＰＣＲ（ＰＣＲ （ｎｅｗ−ＲＴ））を計算する ＰＣＲ（ｎｅｗ−ＲＴ）＝ＤＴＳ（ｃｏｎｔｉｎｕｏｕｓ）−ｄｅｌｔａ（ｎ ｅｗ） 図１１のグラフは、図１０に示されるような新データストリームのリアルタイ ムの送信スタート時間を決定するための好ましい方法によって得られる結果を、 一例の復号器の入力バッファの内容によって示す。簡潔にするために、グラフの 上方部分および下方部分にそれぞれ別個に、旧データストリーム１１０１および ポテンシャル新データストリームの変化１１０２ａ〜１１０２ｃが示されている 。図示するように、上方グラフ部分および下方グラフ部分の各々は、左から右に 増加する際の水平軸に沿った時間の経過および（変更されていない図８ａにおい て単一のＭＰＥＧ−２で符号化されたデータストリームのグラフのように）垂直 位置が増加する場合に増加する入力バッファの内容を示す。更に、旧データスト リーム１１０１に対する垂直曲線部分１１１０および１１２０ａ〜ｃおよびポテ ンシャル新データストリームの変化１１０２ａ〜１１０２ｃのそれぞれによって ＤＴＳ値に従った復号化が示されており、例えば旧データストリーム１１０１に 対する曲線部分１１１２および１１１３によって復号化の間のデータストリーム のデータの受信が示されている。しかしながら、好ましいスプライサーによれば 、新データストリームおよび旧データストリームの図示された部分は、復号器の 入力バッファによっては送受信されないことに留意すべきである。むしろグラフ に示したデータは単に説明のために示したものである。 図示されるように旧データストリームの最終ＤＴＳ値（＋フレーム間遅延時間 、すなわちギャップ）および新ストリームの第１ＤＴＳに関連し、リアルタイム の新ストリームＰＣＲを決定することは、まずこのデータストリームのペアを一 致するように働く。言い換えれば、リアルタイムの新ストリームＰＣＲは、旧ス トリームの最終フレーム１１０３を復号化した約３３ミリ秒（１００１／３０ｍ 秒）の後で、（ＮＴＳＣの場合に）新ストリームの第１フレームを復号化させる 。同様に、新ストリームの第１ＰＴＳも、リアルタイムの新ストリームＰＣＲに 従って決定される。よって、ＮＴＳＣの符号化に対しては旧ストリームの最終フ レームがディスプレイされた約３３ミリ秒後に、新データストリームの提示およ び ディスプレイが開始する。従って、新データストリームはロールオーバーのよう なかかる視覚的アーティファクトを生じることなくディスプレイするよう、シー ムレスに復号化され、定義される。 スプライサーＮ ２７０は、新データストリームの第１シーケンスヘッダーを 探すために、シーケンスファインダー３２０（図３）をスタートさせることによ り、フレーム間ギャップ１１３０を決定する。次に、スプライシングエンジン３ １０はＭＰＥＧ−２の仕様に従ってシーケンスヘッダー内に含まれるフレームレ ート値を探し、次のようにギャップ１１３０を計算する。 １／（フレームレート符号によって示されるフレームレート） ＭＰＥＧ−２仕様によるフレームレート符号は次のフレームレート符号−フレ ームレート値変換テーブルによって示される。 スプライサーＮ ２７０は更に、新データストリームの第１フレームの送信か ら復号化までの実際の、すなわちリアルタイムの遅延時間に従って、リアルタイ ムの新ストリームＰＣＲを決定することも留意すべきである。従って、新データ ストリームの符号化に従って（すなわちスプライシングがない場合にＭＰＥＧ− ２が考えた別個の送受信に従うように）新データストリームのデータのいずれも 、復号器による受信をするように送信される。データストリーム部分の関係を保 留することは特に重要である。その理由は、既に説明したように、適当なＭＰＥ Ｇ −２の符号化によって正しい復号化および提示の双方だけでなく、正しいデータ フローも保証するからである。換言すれば、他の特徴のうちでも特にＭＰＥＧ− ２の符号化を守ることによってデータストリームのデータはデータバッファをオ ーバーフローまたはアンダーフローさせないように保証されるはずである（デー タストリームが正しく符号化されていることを前提とする）。従って、符号化中 に設定されるデータ部分の関係の変更を防止することにより、好ましいスプライ サーはスプライスを完成した後にかかる変更の結果として生じ得る誤りを訂正す ることを不要にする。むしろ、少なくとも好ましいスプライサーに関し、スプラ イスに続く符号化に従って新データストリームが復号化され、提示され続ける。 しかしながら不幸なことに、図１１は旧データストリームを完全に復号化する 前に復号器の入力バッファ内に新データストリームのデータが存在することは問 題となり得ることも示している。第１に、旧データストリームのデータの最終バ ッファフルを復号化する前後で、新データストリームのデータの復号器の入力バ ッファ自身を開始できる。第２に、新データストリームのデータは復号器の入力 バッファをオーバーフローさせるほど、かなりの量になり得る。問題を更に悪く するには、旧データストリームデータの最終フレームを復号化する前に所定時間 内の種々のポイントでかかるオーバーフローが生じる。 図示されるように、時間ｔ２までに旧データストリーム１１０１は復号器の入 力バッファによって受信される。時間ｔ２〜ｔ４の間で、（復号器によって受信 された）残りの旧データストリームのデータのすべてが復号化されるまで復号器 の入力バッファ（すなわち、オールドデータストリームの最後のバッファ）内の 他の残りの旧データストリームのデータは単に復号化されるだけである。第１の 問題（すなわち新データストリームのスタートと旧データストリームの最終バッ ファの開始とを不整合とすること）は、ポテンシャルの新データストリーム１１ ０２に関し、第１の問題（新データストリームのスタートと旧データストリーム の最終バッファ内のスタートとの不一致）はポテンシャル新データストリームに 関し、存在しない。しかしながら、時間ｔ２の前に生じる潜在的な新データスト リーム１１０２ｂ（すなわち初期のデータストリーム）によって示されるように 、新データストリームの初期の受信が早期に生じるようにすることができる。不 幸 なことに、早期データストリームデータが存在することは、（旧データストリー ムのデータの進行中の受信と組み合わせて）オーバーフローを生じさせるだけで なく、同じチャンネルでの多数のデータストリームの並列な送信および受信もＭ ＰＥＧ−２の仕様を破っている。潜在的新データストリーム１１０２ｃ（すなわ ち最終データストリーム）も旧データストリーム１１０１の復号化と共に時々は 時間ｔ２後に生じさせることによりアンダーフローが生じるという問題を有する 。 図１２のフローチャートは、本発明に係わる好ましいスプライサーがどのよう にして本発明に係わる好ましいスプライサーが新データストリームのデータの復 号器の入力バッファの受信の開始時と旧データストリームの最終バッファの開始 時とを整合させるかを示している。広義に述べれば、新データストリームが早期 のデータストリームタイプ（例えば図１１の曲線１１０２ｂ（である場合、スプ ライサーＮ ２７０は、新データストリームのデータの送信を遅延する（等価的 に復号器による遅延を受信する）。その代わりに、新データストリームが最近の ストリームタイプ（図１１の曲線１１０２ｃ）である場合、スプライサーＮ ２ ７０は新データストリームのデータの送信を加速する。（等価的には、復号器に よる受信を加速する。）より詳細には、スプライサーＮ ２７０は好ましくは新 データストリームの送信の開始前にゼロパケットを加えることにより、新データ ストリームのデータを遅延するか、またはデータストリーム内に符号化されてい るゼロパケットを削除することにより、新データストリームの遅延する。スプラ イサーＮ ２７０は後に説明するように、スプライシング中に後で使用するため の、増設された、削除されたゼロパケットの総数を記憶することが好ましい。 図示されるように、ステップ１２１０ではスプライサーＮ ２７０は追加変数 （ゼロカウント）を初期化し、ステップ１２１５でスプライサーＮ ２７０は旧 データストリームの送信の終了点を探す。ステップ１２２０で、リアルタイムの 新データストリームＰＣＲが旧ストリームの最終パケットが送信される時（ＰＣ Ｒｏｌｄ）よりもリアルタイムの新データストリームＰＣＲが短い場合、スプラ イサーＮ ２７０はリアルタイムの新データストリームＰＣＲがＰＣＲｏｌｄに 等しくなるよう、新データストリームの開始点までの十分な数のゼロパケットを 決定し、次のそれに対応してステップ１２４０でゼロカウントを更新する。その 代わりにステップ１２５０で新データストリームが遅れている場合、スプライサ ーＮ ２７０はリアルタイムの新データストリームＰＣＲがステップ１２６０内 でＰＣＲｏｌｄに等しくなるように新データストリームの開始点に近い十分な数 のゼロパケットを削除し、それに対応するステップ１２７０でゼロカウントを更 新する。 しかしながら、スプライサーＮ ２７０はライブラリー機能を有することが好 ましいので、スプライサーＮ ２７０はスプライスバッファ２６５の全サイズは 気にしない。従って、スプライサーＮ ２７０はスプライスバッファＮ ２６５ 内に記憶されたデータストリームのデータからのゼロパケットを安全に除くこと ができ、（よって、スプライスバッファの小さいサイズしか必要としないが、） データストリームのデータ＋増加したゼロパケットはスプライスバッファＮ ２ ６５のサイズを越えることがある。従って、スプライサーＮ ２７０はスプライ スバッファＮ ２６５内に記憶されたデータを送信する前に、多くのゼロパケッ トを加える命令により、ゼロカウントの値をホストアプリケーションへ戻すこと により、ゼロパケットを加算する。当業者が本明細書の説明を検討すれば、完全 なアプリケーションとして機能する本発明に係わるスプライサーは、スプライサ ーが直接ゼロパケットをスプライスバッファに追加できるよう、静的またはダイ ナミックなスプライスバッファのサイズを指定できることが理解できよう。 ゼロパケットと新データストリームとの間の追加および削除は新データストリ ームの符号化特性を維持することに反するが、かかる変更は比較的少量の処理シ ステムのスループットしか必要としない。特にその理由は、必要なＰＣＲ値は既 知であり、先のスプラインスインポイントまたは送信開始時からパケットをカウ ントすることによって必要なＰＣＲｏｌｄを容易に見つけることができるからで ある。更に、特に新データストリームからのゼロパケットを削除すると、入力バ ッファによってデータがより迅速に受信され、この結果、オーバーフローが生じ 得るが、後に更に説明するように、スプライシングの完了前に整合中のデータス トリームの変更の補償が行われる。 図１３ａおよび１３ｂは、本発明に係わる好ましいスプライサーが新データス トリームからゼロパケットをどのように好ましく削除するかを示す。図示するよ うに、スプライスバッファＮ ２６５（図２）には順次順序の定められたコンポ ーネントデータパケットとしてデータストリームのデータが挿入される。このよ うな仕組みにより、更に操作または再編成することなく（すなわち他の編成の代 替例、例えばシーケンス、ＧＯＰ、フレームまたは他のレベルのグラニュラティ に反し）、スプライサーＮ ２７０がパケットレベルでデータストリームのデー タにアクセスし、これを分析し、および／または操作することが可能となってい る。 スプライサーＮ ２７０はスプライスバッファＮ ２６５内の次の新ストリー ムロケーションに残りの各データパケットをコピーすることによりデータパケッ トを削除する。例えば図１３Ａは、スプライスバッファＮ ２６５のロケーショ ン２に含まれるゼロパケットを示す。スプライサーＮ ２７０は先の（すなわち 時間的または等価的に少ない数の）ロケーションに新データストリーム内の残り の各パケットをコピーすることにより、ロケーション２に含まれるゼロパケット を削除し、よってロケーション２に含まれるゼロパケットをオーバーライトし、 その結果、図１３Ｂに示される変更されたスプライスバッファＮ ２６５が生じ る。（データストリーム内の各シーケンスは一般に少なくとも１０％以上のゼロ パケットを含むので、削除できるゼロパケットは見つけられておらず、問題にな りにくい。） 当業者が本明細書の開示内容を検討すれば、スプライスバッファＮ ２６５を 多くの異なるタイプのデータ構造に置換できることが理解できよう。例として、 多次元テーブルおよびリンクされたリストが挙げられるが、これらに限定される ものではない。挿入および削除のための上記コピー方法の利用することも、種々 の従来のリスト取り扱い方法と容易に置換でき、この方法のリンクされたリスト および空のセルが例として挙げられる。好ましい方法は、処理スループットの点 で高価につくが、符号器から直接データを一時的に（スプライス中に）受信し、 データをマルチプレクサバッファにルーティングするだけでなく、スプライスを リアルタイムで実行する費用および複雑さが最小であることに起因し、好ましい 。しかしながら、特に進行中のハードウェアおよびソフトウェアの開発を考慮す れば、他のかかるリストおよびリスト管理方法を使用することも考えられる。 図１４〜１５ｃのフローチャートは、図１１、１６および１７を参照して、本 発明に係わる好ましいスプライサーがスプライシングによって生じる復号器の入 力バッファのオーバーフロー条件をどのように好ましく検出し、訂正するかを示 している（図４のステップ４５０）。 まず、図１１を参照すると、旧データストリーム１８０１の最終復号器バッフ ァは、時間ｔ２前に復号器へ送信される。旧データストリームが（時間ｔ２〜時 間ｔ４の間で）復号化、すなわちプレイアウトし続ける間、（好ましい整合後の ）新データストリーム１１０２ａの第１復号器のバッファは復号器の入力バッフ ァによって連続的に受信される。従って、時間ｔ２〜ｔ４の間で復号器の入力バ ッファにほぼ連続して変化する量の双方のデータストリームが生じ、この場合、 旧データストリーム量は減少し、新データストリーム量は増加する。次に、新デ ータストリームの復号化が時間ｔ５で開始する（すなわち新データストリームの スプライスインポイント）まで、新データストリームの第１復号器のバッファが 復号器によって受信され続ける。当然ながらここに説明した条件はオーバーフロ ーの訂正がない場合に生じる。 図１６のグラフは、復号器の入力バッファ内の新旧データストリームのデータ の例示された部分も示す。しかしながら、図１１と比較すると、旧データストリ ームの最終の復号器のバッファも一部しか示されていない。更に、より上方の多 いデータストリームの例が示されており、新旧データストリームのデータが組み 合わされて示されている。図１６は復号器の入力バッファ内の組み合わされたデ ータストリームが存在することにより、復号器の入力バッファサイズが超過し、 その結果、（ビデオ復号器の入力バッファの）復号器のオーバーフロー状態Ａ、 ＢおよびＣが生じる。不幸なことに、訂正しない場合は、各オーバーフロー状態 の結果、データストリームのデータが喪失することになる。 図１４のフローチャートは本発明に係わる、オーバーフロー状態を除くための 好ましい方法を広義に示す。図示されるように、ステップ１４１０にてスプライ サ−Ｎ ２７０（図３）がスプライスから生じたオーバーフロー状態を見つけた 場合、スプライサーＮ ２７０はステップ１４２０でオーバーフロー状態を生じ させているデータストリーム部分を所定の遅延量だけ遅延する。次に、スプライ サ−Ｎ ２７０はステップ１４３０で遅延量に対応する値だけ、後のデータスト リーム部分を加速する。後に説明するように、スプライサーＮ ２７０はオーバ ーフロー状態（または単なるオーバーフロー）が生じているスプライスバッファ の開始時にゼロパケットを挿入することにより、オーバーフロー訂正中にデータ ストリーム部分を遅延することが好ましい。更にスプライサーＮ ２７０は対応 するスプライスバッファフル状態の開始時またはその近くで、ゼロパケットを削 除することにより、オーバーフロー訂正中のデータストリーム部分を更に加速す ることが好ましい。（先に説明したように、オーバーフロー訂正中に削除のため の十分なゼロパケットが欠如することが発見されないように、符号化の結果とし て一般に１０％以上のゼロパケットを含む。） 更に、スプライサーＮ ２７０はオーバーフローが実際に検出されたデータス トリームのその部分に、ゼロパケットを挿入および／または削除する形態のデー タストリームの変更を局所化することが好ましい。より詳細には、必要に応じ、 新データストリームしか変更せず、新データストリーム内ではオーバーフローが 検出されたスプライスバッファおよび／または特定のスプライスバッファの直前 および／または直後でしか変更しない。当業者が本明細書の内容を検討すれば、 スプライスバッファの開始点以外のデータストリーム内のロケーションで、その ゼロパケット挿入を後の方法で実行できることが理解できよう。例として、オー バーフローが検出されたデータパケットの直前に挿入することが挙げられるが、 このような挿入のみに限定されるものではない。しかしながら、かかる挿入はオ ーバーフロー状態を正確に訂正できるが、同じような有効なオーバーフローの防 止を生じさせるような好ましい方法も判っており、ライブラリーとして実現され たスプライサーによってこの方法をリアルタイムでより容易に達成できる。ゼロ パケット削除についても同様な挿入方法が明らかとなろう。かかる別の挿入方法 は、例えばスプライサーをライブラリー以外のものとして実現し、よってほとん どまたは全くオーバーヘッドを増加することなく、より直接に制御できる。 次に図１６を参照すると、好ましいスプライサーＮ ２７０は組み合わされた データストリームの曲線１６１０に沿ったポイントを好ましく決定することによ り、より詳細にオーバーフロー状態を検出する。図示するように、かかる直線に 沿った測定ポイントは時間ｔ２、ｔ５およびｔ７におけるオーバーフロー状態の スタートを示す。次の工程は復号器の入力バッファの容量が越えているデータ量 を計算すること（およびかかる工程が利用されていること）を含むようであるが 、データストリームのデータ量を越えるバッファによる訂正を行う結果、不正確 な結果となり得ることが判っている。かかる潜在的な不正確さは大部分は共通デ ータストリーム内にビデオ、オーディオおよびその他の情報が存在することに起 因するものである。しかしながら、オーバーフロー状態の長さを測定し、より詳 細にはオーバーフロー状態中に復号器の入力バッファによって受信されるデータ パケット数をカウントすることにより、正確な結果が得られている。混合された データタイプの同じような理由から、フレームごとにカウントされるビデオデー タバイトに対し、データストリームのデータを分析することも好ましい。 説明するように、スプライサーＮ ２７０（図３）は、送信の約１秒前にバッ ファフル（または等価的にはスプライスバッファ）ごとの方式で、スプライスバ ッファＮ ２６５に逐次得られる旧データストリームのデータ、次に新データス トリームのデータを分析することによって、一部機能することが好ましい。従っ て、スプライサーＮ ２７０はスプライスバッファＮ ２６５が対応するデータ ストリーム部分（すなわち旧データストリームの終了部または新データストリー ムの開始部）を含む間、上記機能（例えばスプライスインポイントおよびスプラ イスアウトポイントを探すこと）の各々を実行することが好ましい。スプライサ ーＮ ２７０は更にスプライスイン、スプライスアウト、ＰＣＲおよび整合状態 の決定と共に、スプライステーブル３７０を創出し、オーバーフローの検出およ び訂正に使用するためのデータをスプライステーブル３７０に挿入する（図４の ステップ４０５参照）。 連続するスプライスバッファ中だけでなく、単一のスプライスバッファ中でも ２つ以上のオーバーフロー状態が存在することが判っている。従って、スプライ サーＮ ２７０はスプライスバッファ内に存在し得る全オーバーフロー状態を明 らかにするよう、各スプライスバッファを完全にサーチする。 同じスプライスバッファ内でのオーバーフローの発生は、別個に訂正すべきで ないことも判っている。例えばかかる各オーバーフローは、それに対応してゼロ パケットを挿入することによって防止することが予想されるが、かかる多数の挿 入の結果、あるケースでは符号器のバッファにアンダーフロー状態が生じること が判っている。従って、スプライサーＮ ２７０は好ましくは訂正を実行する前 に、全スプライスバッファ内でオーバーフローの検査／検出を完了することが好 ましい。特に、スプライサーＮ ２７０はスプライスバッファ内の最も長く持続 するオーバーフロー状態を決定し、次にスプライスバッファ前に対応する数のゼ ロパケットを挿入することが好ましい。 ライブラリーに基づく好ましいスプライスバッファＮ ２７０は上記のように オーバーフローの訂正中にゼロパケットを追加したり削除することが好ましいこ とに、更に留意すべきである。より詳細には、データパケットは追加すべき数の ゼロパケットと共にホストアプリケーションへ追加命令を戻すことによって追加 される。これと対照的に、スプライスバッファＮ ２７０はスプライスバッファ Ｎ ２６５から直接ゼロパケットを削除する。 図１５ａ〜１５ｃのフローチャートは、図１７のフレームテーブル例を参照し 、オーバーフロー状態を検出し、除去するための好ましい方法をより詳細に示す 。図１５Ａは、フレームテーブル２６５（図３）に旧データストリームを挿入す るための好ましい方法を示し、一方、図１５ｂおよび１５ｃはフレームテーブル ２６５に新データストリームのデータを挿入し、オーバーフロー状態を検出し、 検出されたオーバーフロー状態を除去するための好ましい方法を示す。 図１５Ａに示されるように、スプライサーＮ ２７０はスプライステーブルＮ ３７０に、スプライスバッファＮ ２６５に含まれる旧データストリームのビ デオフレームのサイズおよびＤＴＳを挿入することにより、オーバーフロー状態 の取り扱いを開始することが好ましい。スプライサーＮ ２７０はほぼ起動時に 開始することが好ましいが、スプライサーＮ ２７０はスプライステーブル３７ ０が旧データストリームの最終復号器のバッファに対する完全なデータを含むこ とを保証するよう、十分早期に開始するだけでよい。スプライサーＮ ２７０は 既に説明したように、シーケンス、ＧＯＰ、パケットおよびフレームデータのた めにスプライスバッファＮ ２６５を分析する。上記のように、スプライサーＮ ２７０はスプライスバッファＮ ２６５に含まれる各パケット内のビデオフレ ー ムデータバイトをカウントすることにより、フレームサイズを決定することが更 に好ましい。 より詳細には、ステップ１５０１でスプライスバッファＮ ２６５が旧データ ストリームのデータの新スプライスバッファを含む場合、スプライサーＮ ２７ ０はステップ１５０３で最初のフレーム（すなわち現在フレーム）のために、ス プライスバッファＮ ２７６を分析する。次に、スプライサーＮ ２７０はステ ップ１５０５で現在フレームのためのＤＴＳを検索し、ステップ１５０７でフレ ームテーブルＮ ３７０の次のロケーションに検索したＤＴＳを記憶する。 ステップ１５０９で、スプライスバッファＮ ２６５内に、より多くのデータ が残っている場合、スプライサーＮ ２７０はステップ１５１０でスプライスバ ッファＮ ２６５内の次のデータパケットを入手し、ステップ１５１１で、現在 のパケットが新しいフレームであるかどうかを判断する。ステップ１５１１で現 在パケットが新しいフレームである場合、スプライサーＮ ２７０はスプライス テーブルＮ ３７０内に以前のビデオフレームのサイズを記憶し、ステップ１５ ０５にリターンする。新フレームでない場合、スプライサーＮ ２７０は、ステ ップ１５１３で現在フレームに対する進行中の総数に現在パケット内のビデオデ ータバイトの数を加算し、ステップ１５０９へリターンする。 ステップ１５０９で、スプライスバッファＮ ２６５内にもうデータが残って いない場合、スプライサーＮ ２７０はステップ１５１４へ進む。ステップ１５ １４にてスプライスバッファＮ ２６５が旧データストリームのデータの最終ス プライスバッファを含んでいない場合、スプライサーＮ ２７０はステップ１５ ０１へ進む。この代わりに、ステップ１５１４でスプライスバッファＮ ２６５ が旧データストリームのデータの最終スプライスバッファを含む場合、スプライ サーＮ ２７０はステップ１５１５で第１ポインタを初期化し、旧データストリ ームの最終復号器のバッファの第１フレームのロケーションを（フレームテーブ ルＮ ３７０内で）ポイントする。 新データストリームに関する図１５ｂにおいて、スプライサーＮ ２７０はま ず既に復号器の入力バッファに含まれる旧データストリームのデータに新データ ストリームのデータを加えることによって、越えることのできない（すなわちオ ーバーフローできない）バッファを決定することが好ましい。より詳細には、ス テップ１５２１でスプライサーＮ ２７０は新データストリームの第１シーケン スヘッダー内のｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅフィールドの値に対する可変サ イズをセットする。このｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ値は各受信復号器の入 力バッファの利用できる総サイズ（このサイズは変わり得る）を必ずしも示すも のではないが、この値は新データストリームの符号化中に予想される最大バッフ ァサイズを示す。従って、スプライサーＮ ２７０はかかるサイズを想定するこ とにより、スプライシングをすることなくオーバーフローが生じなかった（すな わち復号器の入力バッファを１つの符号化されたデータストリームしか占めてい ない）場合に、オーバーフローが生じないことを保証する。スプライサーＮ ２ ７０は更にステップ１５２３で、ゼロを加えるかどうかを判断するのに使用する ための可変（追加ゼロ）を初期化し、ゼロを加算する場合、どれだけ多くのゼロ を加算すべきかを判断する。 図１７は、例としてオーバーフローを検出するのにバッファテーブルＮ ３７ ０をどのように使用するかを示す。図示するように、このポイントにてスプライ サーＮ ２７０は（連続するスプライスバッファ内の）オーバーフローおよびそ れに対応して旧データストリームのＤＴＳおよびフレームサイズの各々によって 満たされたフレームテーブルＮ ３７０を見つけている。更に、スプライサーＮ ２７０は旧データストリームの最終復号器のバッファの第１フレームをポイン トするためのスタートポインタを既にセットしている。しかしながら、（図示さ れているテーブルの下方部分内の）新しいデータストリームに関し、スプライサ ーＮ ２７０は第１フレームに対するＤＴＳをアサートすることにより開始し、 次に第１フレームに対するフレームサイズの決定を開始する。スプライサーＮ ２７０がこのサイズの決定を完了するまで、このサイズは単に進行中であり、次 のフレームの検出によって完了すると、現在のフレームサイズが固定状態となる 。 フレーム計算と同時に、スプライサーＮ ２７０はオーバーフローを検査し、 形成する。正しく符号化されたデータストリームは単独ではオーバーフローを生 じないので、オーバーフローを検査することなく、旧データストリームのサイズ の値を合計できる。しかしながら、新データストリームのデータパケットの未知 のパケットによりオーバーフローが生じる。従って、スプライサーＮ ２７０は 各パケットを分析した後に、進行中のサイズの決定の完了時にオーバーフロー（ すなわちｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅを越えること）を検査することが好ま しい。いったん固定されると、新データストリームのフレームサイズを旧データ ストリームのフレームサイズと共に直接合計できる。しかしながら、ＭＰＥＧ− ２で符号化されたフレームが開始し、フレームバッファ、更にパケットの境界部 を横断して終了できるが、オーバーフローの決定および訂正はスプライスバッフ ァごとの方式で実行することが好ましいと留意すべきである。 括弧１７１０および１７１２は、スタートポインタがインクリメントする状態 で、旧データストリームの連続する各フレームで開始しながら、オーバーフロー の検査をどのように行うのが好ましいかを示す。表示を簡単にするため、図１５ ａ〜１５ｃのフローチャートは各旧データストリームの復号化によってオーバー フローを解決することを想定している。図１６のグラフに戻ると、これまで発見 されたすべてのオーバーフロー状態を示すオーバーフロー状態ＡおよびＢは、オ ーバーフローのかかる復号器による解決を示す。しかしながら、復号化によって オーバーフロー状態（すなわちオーバーフローＣ）を治癒できないオーバーフロ ー状態も生じ得ることに留意すべきである。従って、かかるオーバーフローを傍 観することを防止するために、現在のサイズ決定から各復号化されたフレームの サイズを減算し、オーバーフローが持続しているかどうかを判断するために再び 検査を実行すべきである。オーバーフローが持続している場合、オーバーフロー の最中のパケット数の決定を続行すべきである。しかしながら、更に必要となる 時間およびスペース条件が仮定された場合、オーバーフローＣタイプの発生の検 査を選択的に行うことが好ましい。 当業者が本明細書の内容を検討すれば、本発明の要旨および範囲から逸脱する ことなく、特定のスプライステーブル構造および特定の方法のパラメータを変更 してもよいことが理解できよう。 図１５Ｂに戻ると、ステップ１５２５で、スプライサーＮ ２７０はスタート ポインタが示すロケーションから開始し、スプライステーブルＮ ３７０内の既 知のすべてのビデオ−フレームサイズを合計する。ステップ１５２７でスプライ サーＮ ２７０は新データストリームの第１フレームに対するＤＴＳをスプライ ステーブルＮ ３７０へ入力し、フレームサイズを０に等しくなるように初期化 する。ステップ１５２９で、スプライサーＮ ２７０はスプライスバッファＮ ２６５の現在パケット内のビデオデータバイトの総数を入手し、この数を現在フ レームに対するフレームサイズに加算する。 ステップ１５３１で、追加される新データストリームのデータバイトの結果、 オーバーフロー状態が生じると、スプライサーＮ ２７０はステップ１５５１（ 図１５ｃ）へ進み、オーバーフロー状態が生じない場合、スプライサーＮ ２７ ０はステップ１５３３に進む。 ステップ１５３３で、新データストリームの現在のデータパケットに対するＰ ＣＲ値は、（旧データストリームの）スタートフレームのＤＴＳ以上である場合 、旧データストリームの復号化が行われ、ステップ１５３５が示すように、次の 旧データストリームのフレームに関してオーバーフローの検出を再開できる。そ の代わりに、ステップ１５３３でＰＣＲの値が現在のスタートフレームＤＴＳ以 上でない場合、スプライサーＮ ２７０はステップ１５３５へスキップし、ステ ップ１５３７へ続く。 ステップ１５３７で、スプライスバッファＮ ２６５の終了部に達すると、ス プライサーＮ ２７０は（図１５Ｃの）ステップ１５５７へ進み、そうでない場 合、スプライサーＮ ２７０は次のパケット内のビデオバイトを合計するか、ま たは新フレームに達した場合、フレームテーブル３７０へフレームサイズの合計 を入力し、現在のフレームサイズを再初期化し、ステップ１５３１へ進むことに より、ステップ１５３９でビデオバイトカウントを続ける。 図１５Ｃは、検出されたオーバーフロー状態の開始に応答してステップ１５５ １でスタートする。上記のようにスプライサーＮ ２７０は、現在のバッファ中 にオーバーフロー状態が持続する間のパケット数を決定し、現在のスプライスバ ッファ内のかかる最大の持続時間に等しいゼロパケット数を加算する。ステップ １５５１で、スプライサーＮ ２７０は、（現在のパケットヘッダーから）現在 のパケットに対するパケット数を入手する。ステップ１５５３で、スプライサー Ｎ ２７０は次のパケットから、または以前と同じようにビデオバイト数を入手 し、次のパケットが新フレームを開始する場合、スプライサーＮ ２７０は先の フレームサイズをバッファテーブルＮ ３７０へ入力し、現在のフレームサイズ を再初期化する。 オーバーフロー状態に達し、ステップ１５５５において、現在のスプライスバ ッファの終端部に達した場合、スプライサーＮ ２７０はステップ１５６５に進 む。その代わりに、オーバーフロー状態に達し、ステップ１５５５で現在スプラ イスバッファの終端部に達した場合、スプライサーＮ ２７０はステップ１５５ ７で現在スプライスバッファ中にオーバーフローが持続している間に、パケット の最大数に等しい現在のスプライスバッファにゼロパケットの数を加え、ステッ プ１５５９へ進む。 ステップ１５５９で、終了状態に達すると、スプライスを完了し、そうでない 場合、スプライサーＮ ２７０はステップ１５６１へ進む。スプライサーＮ ２ ７０は新データストリームが符号化された状態で続く時（すなわちスプライシン グ中に行われる変更前）に生じる終了条件を決定することが好ましい。従って、 符号化された新データストリームが閉じたＧＯＰで開始した場合、現在のスプラ イスバッファの現在パケットに対するＰＣＲが、符号化された旧データストリー ムの最終ＤＴＳ以上となった時に、終了状態に達する。しかしながら、新データ ストリームのスタート時（すなわちビデオスプライスインポイントを探す間）、 スプライサーＮ ２７０がオープンＧＯＰを閉じた場合、スプライサーＮ ２７ ０は新データストリームへのＤＴＳｎ＋１フレーム（ここでｎはスプライサーＮ によってドロップされたフレーム数である）を探した時に、終了状態に達する。 例えばスプライサーＮ ２７０が２つのフレームをドロップすることによってＧ ＯＰを閉じた場合、スプライサーＮ ２７０が新データストリームの第３フレー ムに対するＤＴＳを探した時に、終了状態に達する。 ステップ１５６１では（すなわちオーバーフローが発見され、現在のスプライ スバッファの終了部に達しているが、終了状態は存在していない場合）、スプラ イサーＮ ２７０は次のスプライスバッファの開始点からゼロの数を減算し、ゼ ロカウントを初期化し直す。次に工程１５６３で、スプライサーＮ ２７０はス プライスバッファの次の（このケースでは最初の）パケットに対するサイズを入 手することにより、オーバーフローに関し、新スプライスバッファの検査を開始 するか、または新フレームが発見された場合、旧フレームサイズをバッファテー ブルＮ ３７０へ入力し、新フレームサイズをゼロバイトとして初期化する。次 にスプライサーＮ ２７０は（図１５Ｂの）ステップ１５３１へ進む。 好ましいスプライサーは次のスプライスバッファから同じ数のゼロパケットを 削除することにより、ゼロパケットを追加したスプライスバッファに従うことが 好ましいが、当業者が本明細書の内容を検討すれば、中間削除以外の回復方式と 置換できることも理解できよう。上記のように、スプライシングを終了する前に 新データストリームの残りのストリームを符号化された状態に回復することは、 進行中の介入を必要とすることなく、スプライシング後に別のオーバーフロー、 アンダーフローおよび／または他の異常を防止するように働く。従って、ゼロを 加えた後にゼロを削除し、すなわち符号化されたストリームを回復することが好 ましい。更に削除は、アンダーフローを生じさせるような、例えば長い遅延を防 止するように、十分近似した加算に従うべきである。しかしながら、変形例とし て特定の追加と削除との間を、より近くすることが挙げられるが、これに限定さ れるものでなく、同じバッファがオーバーフローとアンダーフローとを生じさせ ることはできないとみなす。 次に図１５Ｃに戻る。ステップ１５６５で、スプライサーＮ ２７０はスプラ イスバッファの次のパケットに対するサイズを入手し、新フレームが見つかった 場合、バッファテーブルＮ ３７０に旧フレームサイズを入力し、新フレームサ イズを初期化する。次にスプライサーＮ ２７０はステップ１５６７に進む。ス テップ１５６７で、現在のスプライスバッファの終了部に達した場合、スプライ サーＮ ２７０はステップ１５５７に進む。そうでない場合、スプライサーＮ ２７０はステップ１５６９に進む。ステップ１５６９において、現在のスプライ スバッファの現在パケットに対するＰＣＲ値が、スタートフレームのＤＴＳ以上 となった場合、スプライサーＮ ２７０は、ステップ１５７１において現在のス プライスバッファの間でオーバーフローが持続している間、パケットの最大数に 等しくなった現在のスプライスバッファに多数のゼロパケットを加え、ステップ １５６３に進み、そうでない場合、スプライサーＮ ２７０はステップ１５７１ をスキップし、ステップ１５６３に進む。 次に図１８〜２０を参照すると、スプライサーＮ ２７０はビデオスプライシ ングと組み合わせてオーディオスプライシングを行う。より詳細には、スプライ サーＮ ２７０はビデオスプライスアウトポイントを探した後に、旧データスト リームのオーディオスプライスアウトポイントを探し（図４のステップ４１０） 、同様にビデオスプライスインポイントを探した後に新データのオーディオスプ ライスインポイントを探す（図４のステップ４２０）。 図１８のフローチャートは、旧データストリーム内のオーディオスプライスア ウトポイントをセットするための好ましい方法を示す。図示するように、ステッ プ１８１０でビデオスプライスアウトポイントが見つかると、ステップ１８２０ でスプライサーＮ ２７０は先の最後のオーディオパケットのためのスプライス バッファＮ ２６５（図３）を分析する。次に、ステップ１８３０でスプライサ ーＮ ２７０はオーディオスプライスアウトポイントと、それに続くビデオスプ ライスアウトポイントとの間に生じるギャップをゼロパケットで満たす。 図１９Ａのグラフに示されるように、図１８の方法はスプライス前のビデオの 終了前にポイント１９０１でオーディオを終了する。かかるスプライスアウトは ビデオ画像を終了する前に無音状態を発生するが、この結果生じる２０〜３０ｍ 秒の無音状態は許容できるものであるとみなされる。これとは異なり、（オーデ ィオＤＴＳとビデオＤＴＳを一致させることにより）無音状態が発生しないよう に保証することによって、ビデオが終了後にオーディオ１９０２が持続するとい う問題が生じる。更に、過剰のオーディオデータはオーバーフロー状態をより発 生し易くする。 図２０のフローチャートは、図１９Ｂを参照しながら、新データストリーム内 のオーディオスプライスインポイントをセットするための好ましい方法を示す。 図示するように、ビデオスプライスインポイントがステップ２０１０で発見され 、ステップ２０２０で早期のアウトオプションが選択された場合、スプライサー Ｎ ２７０はステップ２０５０で、ビデオスプライスインポイント（図１９Ｂの １９０５）に続くオーディオヘッダー境界部を探す。ビデオがスタートした後に 、無音時間が存在するので、スプライサーＮ ２７０は、失ったオーディオパケ ット （図９Ｂの１９５０）をゼロパケットに置換する（ステップ２０６０）。この代 わりに、ステップ２０２０でＰＴＳマッチングオプションが選択されている場合 、スプライサーＮ ２７０はステップ２０３０でビデオＰＴＳよりも大きい第１ オーディオＰＴＳを探し、オーディオのスタート（図１９Ｂの１９６０）までの 無音時間をステップ２０４０でゼロパケットに置換、すなわちパディングする。 再度、早期オプション外の短期間の無音状態が好ましい。 図２１および２２は、本発明の別の好ましい実施例を示す。広義に説明すれば 、本実施例は先の実施例のスプライサーと同様にスプライスを実行するスプライ サーを提供するものである。しかしながら、本実施例のスプライサーは、好まし くはマルチプレクサ状に実現されたビットクロックと組み合わされて機能する。 かかるビットクロックおよびその他の関連する利益を利用することにより、好ま しいスプライサーによりスプライスを実行するための処理条件を実質的に低減で きる。 従来、チャンネルマルチプレクサは、データストリームのデータを順次受信し 、これらデータストリームを多重化し、多重化されたデータを送信機へルーティ ングするよう、繰り返し状態で作動している。かかるシステムでは、マルチプレ クサにより受信する前にデータストリームは完全に処理しなければならない。し かしながら、マルチプレクサがスプライサー動作を容易にできるよう、スプライ サーとマルチプレクサとの間で共通のタイミング基準を設定できることが判って いる。 図２１は、スプライサー動作と共にビットクロックがどのように作動するかを 一般に示す。図示するように、ステップ２１０５で、ユーザーはマルチプレクサ のビットレートをセットする。ステップ２１１０で、ホストアプリケーションは マルチプレクサ１９０（図２）にアクティーブスプライスバッファの各々に対す る送信ビットレートを送る。ステップ２１１５で、ホストアプリケーションはマ ルチビットレートに対するチャンネルビットレートの比に従ってバッファ送信ス ケジュールをセットする。ステップ２１２０で、マルチプレクサ１９０はスプラ イサーバッファＮ ２６５がスケジュールどおりに送信準備状態となっていない 場合にゼロパケットを送る。ステップ２１２５で、スプライサーＮ ２７０はス プライスバッファＮ ２６５の内容と共に、ホストアプリケーションに対し、マ ルチプレクサ１９０によって命令が受信されると、ｎ個のゼロパケットを削除す る。 （ｎの値はゼロパケット削除命令に対しては負であり、ゼロパケット追加命令 に対しては正である。）ステップ２１３０で、マルチプレクサ１９０は送信機へ スプライスバッファＮ ２６５の内容をルーティングし、送信機は即座に次の式 によって示される時間にスプライスバッファを送信する。 送信時間＝スケジュール（ビット）＋｛ｎ（パケット）×１５０４（ビット／ パケット）×マルチプレクサのビットレート｝÷データストリームビットレート スプライサーＮ ２７０は先の実施例（図１３ａおよび１３ｂ）のゼロパケッ トを削除するためのマルチコピー方法よりも実質的に少ない処理パワーを使って 、スプライスバッファを加速するだけであることに留意すべきである。更に、ス プライサーＮ ２７０は先の実施例と同じように機能できる。スプライサーＮ ２７０は同じように遅延を実行し（すなわち０を加え）、加速を実行（すなわち ０を削除）するので、更に最適にすることができる。 図２２のフローチャートは本スプライサーが図１４〜１５ｃに記載されたオー バーフロー検出および訂正方法をどのように最適化するかを示す。広義に説明す れば、新データストリームを別個に回復し、次に同じスプライスバッファに対し てオーバーフローを訂正する、図１５ａ〜１５ｃの方法と対照的に、本スプライ サーはスプライサーバッファ１つにつき１つの命令しか与えないことが好ましい 。更に本スプライサーは、好ましくは従来の方法と同じように、ゼロパケットを 削除、追加する他に、スプライスバッファのシフト送信に対するビットクロック と組み合わせて機能させることが好ましい。 図示するように、ステップ２２０５で、スプライサーＮ ２７０が新データス トリームの第１スプライスバッファを分析することにより、１つ以上のオーバー フロー状態を検出した場合、ステップ２２１０でスプライサーＮ ２７０は（先 の実施例と同じように）オーバーフロー中に最大のパケットに等しい追加ゼロを セットし、更に追加ゼロに等しい削除ゼロをセットする。新データストリームを 回復するために、次のスプライスバッファと共に削除ゼロが使用される。次に、 ステップ２２１５で、スプライサーＮ ２７０はホストアプリケーションを介し 、マルチプレクサ１９０にゼロパケット追加命令を送る。その代わりに、ステッ プ２２０５でオーバーフロー状態が検出されなければ、スプライサーＮ ２７０ はステップ２２０７で追加ゼロおよび削除ゼロをゼロにセットする。 ステップ２２２０で、スプライサーＮ ２７０が次のスプライサーバッファを 分析中にオーバーフロー状態を検出した場合、このスプライサーＮ ２７０はス テップ２２２５でスプライスバッファに対する最大時間のオーバーフロー中のパ ケット数を記憶し、ステップ２２３０で、オーバーフロー訂正値とストリーム解 決ゼロパケット値との差をホストアプリケーションへ送り（すなわちゼロパケッ トをそれぞれ追加および削除し）、ステップ２２３５で、追加ゼロに等しくなる ように削除ゼロをセットし、追加ゼロパケットをゼロにセットする。従って、上 記のようにスプライサーＮ ２７０はスプライスフレームに対し１つの組み合わ せ命令しか与えないことが好ましい。ステップ２２６０で、スプライサーＮ ２ ７０が（先に説明したような）終了状態に達していない場合、スプライサーＮ ２７０はステップ２２２０へ進む。 ステップ２２２０において、スプライサーＮ ２７０が次のスプライスバッフ ァを分析中にオーバーフロー状態を検出しない場合、スプライサーＮ ２７０は ステップ２１４０へ進む。ステップ２１４０で、削除ゼロがゼロに等しい場合、 スプライサーＮ ２７０はステップ２２６０へ進む。その代わりに、ステップ２ １４０で追加ゼロがゼロに等しくない場合、スプライサーは対応する削除ゼロ命 令をステップ２２４５でホストアプリケーションへ送り、ステップ２２５０で削 除ゼロをゼロに等しくなるようにセットする。 当業者が以上の説明を検討すれば、新旧データストリームが他の方法で異なる ように、または同じように符号化されている場合でも、本明細書に記載した実施 例のいずれも実施可能であることが理解できよう。例えば、好ましいスプライサ ーは共通する時間基準、例えば共通ＰＣＲを選択的に利用および／またはセット することができる。いずれのスプライサーも、出力デバイス、例えばマルチプレ クサ１９０（図２）と直接通信するようにも構成できる。更に、説明したゼロパ ケットからビットクロックスケジュールオフセットへの変換はスプライサーおよ び／またはホストアプリケーションによって実行できる。 以上で本発明の特定の実施例を参照し、本発明について説明したが、ある範囲 の変更、種々の変形および置換はこれまでの開示の範囲内のものであり、ある場 合にはここに説明した発明の要旨および範囲から逸脱することなく、また他の特 徴を対応して使用することなく、本発明の一部の特徴を利用できることが理解で きよう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ 【要約の続き】 トリームのデータの部分を遅延または加速することが好 ましい。

Claims (1)

1. 【特許請求の範囲】 １．オーバーフロー状態を生じさせる、デジタル式に符号化された第１データ ストリーム部分を検出する工程と、 前記オーバーフロー状態を防止する遅延時間の間、前記第１データストリーム 部分を遅延する工程と、 前記遅延時間を実質的に補うよう、前記第１データストリーム部分に先行する 第２データストリーム部分を加速する工程とを備えた、オーバーフロー状態を除 くための方法。 ２．オーバーフロー状態を生じさせる、デジタル式に符号化された第１データ ストリーム部分を検出する手段と、 前記第１データストリーム部分を遅延するための手段と、 前記第１データストリーム部分に先行する第２データストリーム部分を加速す るための手段とを備えた、オーバーフロー状態を除くための装置。 ３．新データストリームの一部と旧データストリームの一部とを含む復号器の バッファのオーバーフローを防止するための方法であって、 （ａ）前記復号器のバッファに送信した場合、前記復号器の場合を占有する、 旧データストリームデータの総量を決定する工程と、 （ｂ）組み合わされた量のデータを得るよう、前記総量に対してある量の新デ ータストリームデータを追加する工程と、 （ｃ）前記組み合わされた量のデータが前記復号器のバッファをオーバーフロ ーさせるかどうかを検査する工程と、 （ｄ）オーバーフローが生じる場合、新データストリームの一部を前記復号器 のバッファに送ると、少なくとも前記オーバーフローに対応する遅延量だけ、新 データストリームの一部を遅延させる工程とを備えた、復号器のバッファのオー バーフローを防止するための方法。 ４．前記決定する工程（ａ）に前記復号器のバッファの最大サイズを決定する 工程が先行する、請求項３記載の方法。 ５．旧データストリーム内のバッファサイズパラメータに従って前記最大サイ ズを決定する、請求項４記載の方法。 ６．新データストリーム内のバッファサイズパラメータに従って、工程（ａ） の前記最大サイズを決定する、請求項４記載の方法。 ７．工程（ｃ）の検査に先立ち、前記総量から送信した場合に前記復号器によ って復号化される旧データストリームのデータ量を減算することを更に含む、請 求項３記載の方法。 ８．工程（ｄ）の前記遅延量が、新データストリームの前記部分内で前記バッ ファがオーバーフローしたデータストリームのデータの量の関数である、請求項 ３記載の方法。 ９．工程（ｄ）の前記遅延量が、新データストリームの前記部分内で１回のオ ーバーフローで前記バッファがオーバーフローしたデータストリームのデータの 量の関数である、請求項３記載の方法。 １０．工程（ｄ）の前記遅延量が、新データストリームの前記部分内のオーバ ーフローの期間の関数である、請求項３記載の方法。 １１．工程（ｄ）の前記遅延量が、新データストリームの前記部分内の１回の オーバーフローの期間の関数である、請求項３記載の方法。 １２．工程（ｄ）の前記遅延量が、新データストリームの前記部分内のオーバ ーフローの最長期間の関数である、請求項３記載の方法。 １３．工程（ｄ）の前記遅延量が、新データストリームの前記部分内のオーバ ーフローの最長期間中の前記部分のデータパケットの数に等しい、請求項３記載 の方法。 １４．新データストリームを送信する場合、前記遅延量に対応する加速量だけ 、前記新データストリームのその後の部分を加速させることを、前記工程（ｄ） が更に含む、請求項３記載の方法。 １５．旧データストリーム部分と新データストリーム部分とを含むデータスト リーム部分をスプライスする間の、データストリーム復号器のオーバーフローを 検出する方法であって、 （ａ）前記旧データストリーム部分の旧データストリームフレームに対応する 複数の旧データストリームフレームサイズおよび復号化時間を決定し、前記フレ ームサイズおよび前記復号化時間をスプライステーブル内に記憶する工程と、 （ｂ）最大復号器のバッファサイズを決定する工程と、 （ｃ）新データストリーム部分の新データストリームフレームに対応する新フ レームサイズおよび復号化時間を決定する工程と、 （ｄ）スプライステーブル内に記憶されている複数の旧データストリームフレ ームサイズを合計することにより、中間サイズを決定する工程と、 （ｅ）新データストリームフレームサイズを前記中間サイズに加えることによ り総サイズを決定する工程と、 （ｆ）前記総サイズが前記最大復号器のバッファサイズを越えるかどうかを判 断することにより、オーバーフローを検査する工程とを備えた、オーバーフロー を検出するための方法。 １６．データストリーム部分を送信する場合に、前記新データストリームフレ ームが復号器により受信される際に、復号化されない状態のままとなる、旧デー タストリーム部分のすべてのフレームを工程（ｄ）の前記旧データストリームの フレームサイズが含む、請求項１５記載の方法。 １７．データストリーム部分を送信する、請求項１６記載の方法。 １８．（ａ）工程（ｆ）でオーバーフローが発見された場合、前記新データス トリームのフレームを含む新データストリームのデータの一部の送信時間を遅延 させる工程を含む、請求項１５記載の方法。 １９．新データストリームのデータの一部のスケジュールされた送信時間の遅 延を生じさせることを含む、旧データストリーム部分および新データストリーム 部分を有するデータストリーム部分のスプライス中に、デジタル式に符号化され たデータストリームの復号器のオーバーフローを訂正するための方法。 ２０．前記遅延が、前記新データストリーム部分にゼロパケットを追加するこ とによって行われる、請求項２０記載の方法。 ２１．次の式 （前記部分に対して現在スケジュールされている送信時間）＋（（ｎ個のパケ ット×ｍ個のビット／パケット×マルチプレクサのビットレート）／（データス トリームのビットレート））（ここでｎは送信を遅延すべきパケット数を示し、 ｍは送信すべきデータストリームのデータのパケット内のビット数を示す）に従 って、前記部分の送信をスケジュールし直すことによって前記遅延を生じさせる 、請求項１９記載の方法。 ２２．ｍが１５０４に等しい、請求項２１記載の方法。 ２３．旧データストリームおよび新データストリームを含むデジタル式に符号 化されたデータストリームをスプライスする方法であって、 （ａ）旧データストリームのスプライスアウトポイントおよび新データストリ ームのスプライスインポイントに対応して新データストリームの現在の時間基準 を変更し、よって変更された新データストリームのタイミング基準を形成する工 程と、 （ｂ）再生中の旧データストリームから新データストリームへの移行を実質的 に認識できないように、前記変更された新データストリームのタイミング基準に 従って新データストリームの一部と旧データストリームの一部とを整合させる工 程とを備えた、デジタル式に符号化されたデータストリームをスプライスするた めの方法。 ２４．工程（ａ）の前記変更された新データストリームのタイミング基準が、 旧データストリームの最終フレームを復号化するための第１復号化時間と新デー タストリームの第１フレームを復号化するための第２復号化時間との間のタイミ ングギャップに更に対応する、請求項２３記載の方法。 ２５．前記変更された新データストリームのタイミング基準を決定する工程が 、 （ｉ）新データストリームの前記現在のタイミング基準を決定する工程と、 （ｉｉ）前記現在のタイミング基準と新データストリームのフレームの現在の 復号化時間との間の遅延時間を決定する工程と、 （ｉｉｉ）旧データストリームの最終フレームを復号化するための復号化時間 と新データストリームの第１フレームを復号化するための復号化時間との間の、 フレーム間遅延時間と前記現在の復号化時間との合計に対応する新データストリ ームの前記フレームの新復号化時間を決定する工程と、 （ｉｖ）工程（ｉｉｉ）の前記新復号化時間から工程（ｉｉ）の前記遅延時間 を引いた時間として、前記変更された新データストリームのタイミング基準を決 定する工程とを含む、請求項２３記載の方法。 ２６．前記変更された新データストリームのタイミング基準を決定する工程が 、 （ｉ）前記新データストリームの第１パケットのプログラムクロック基準を決 定する工程と、 （ｉｉ）前記新データストリームの第１シーケンスヘッダーの送信から前記新 データストリームの第１フレームの第１復号化時間スタンプ（ＤＴＳ）との間の 遅延時間を決定する工程と、 （ｉｉｉ）前記第１ＤＴＳとフレーム間遅延時間の合計として連続ＤＴＳを決 定する工程と、 （ｉｖ）工程（ｉｉｉ）の前記連続ＤＴＳ−工程（ｉｉ）の前記遅延時間とし て新データストリームのリアルタイム送信時間を決定する工程とを含む、請求項 ２３記載の方法。 ２７．工程（ｂ）における前記整合が、旧データストリームの一部を復号化す るための復号化時間に対応する新データストリームの一部を送信するための開始 時間を設定する、請求項２３記載の方法。 ２８．工程（ｂ）における前記整合が、旧データストリームの一部を復号化す るための復号化時間に対応する新データストリームの一部の受信を開始するため の復号器のバッファのための開始時間を設定する、請求項２３記載の方法。 ２９．（ｄ）データストリームが送信された場合、前記スプライシングから生 じる復号器のバッファのオーバーフロー状態を検出する工程と、 （ｅ）前記オーバーフロー状態を訂正する工程を更に含む、請求項２３記載の 方法。 ３０．工程（ａ）の前記工程に、 （ｉ）旧データストリームのスプライスアウトポイントを決定する工程と、 （ｉｉ）新データストリームのスプライスインポイントを決定する工程が先行 する、請求項２３記載の方法。 ３１．新データストリームの初期フレームが、先のフレームの復号化に対する 基準により通常復号化されたタイプである場合、工程（ｉｉ）が前記基準を除く よう、新データストリームを変更する工程を含む、請求項３０記載の方法。 ３２．ＢフレームおよびＰフレームから成る群から前記フレームタイプが選択 されており、前記変更する工程が、画像のオープングループ（ＧＯＰ）を閉じる ことを含む、請求項３１記載の方法。 ３３．前記データストリームがビデオおよびオーディオデータを含み、工程（ ａ）がビデオスプライスアウトポイントおよびオーディオスプライスアウトポイ ントを決定することを含み、工程（ｂ）がビデオスプライスインポイントおよび オーディオスプライスインポイントを決定することを含む、請求項３０記載の方 法。 ３４．工程（ｉ）の前記スプライスアウトポイントが旧データストリームのユ ーザーが選択可能な部分内で決定される、請求項３０記載の方法。 ３５．工程（ｉｉ）の前記スプライスインポイントが旧データストリームのユ ーザーが選択可能な部分内で決定される、請求項３０記載の方法。 ３６．工程（ｉ）の前記スプライスアウトポイントがユーザーによって選択可 能である、請求項３０記載の方法。 ３７．工程（ｉｉ）の前記スプライスインポイントがユーザーによって選択可 能である、請求項３０記載の方法。 ３８．工程（ａ）に対し、旧データストリームのための第１ソースを決定する こと、および新データストリームに対する第２ソースを決定することが先行する 、請求項２３記載の方法。 ３９．前記ソースが記憶デバイス、衛星受信機、ケーブル受信機、ネットワー ク、オーディオソース、ビデオソースおよび符号器から成る群から選択したソー スのタイプを含む、請求項３８記載の方法。 ４０．前記第１ソースと前記第２ソースとが同じソースタイプのものである、 請求項３９記載の方法。 ４１．前記データストリームの少なくとも１つをＭＰＥＧで符号化する、請求 項２３記載の方法。 ４２．前記スプライシングをリアルタイムで行う、請求項２３記載の方法。 ４３．工程（ａ）の後に、旧データストリームの一部を送信することが続く、 請求項２３記載の方法。 ４４．工程（ｂ）の後に、旧データストリームの一部を送信することが続く、 請求項２３記載の方法。 ４５．請求項２３の方法に従って共にスプライスされた旧データストリームと 新データストリームとを含むデータがスプライスされたデータストリームの組み 合わせ。 ４６．（ａ）旧データストリーム内のスプライスアウトポイントを決定する工 程と、 （ｂ）新データストリーム内のスプライスインポイントを決定する工程 と、 （ｃ）新データストリームのリアルタイムの送信開始時間を決定する工 程をコンピュータに実行させるためのプログラム符号を記憶するコンピュータで 読み取り可能な記憶媒体。 ４７．工程（ａ）の前に、 別のデータストリームペアと同時にスプライスすべき新データストリームペア を決定する工程と、 前記新データストリームペアをスプライスするためのプログラム符号を開始す る工程とが先行する、請求項４６記載の、コンピュータで読み取り可能な記憶媒 体。 ４８．工程（ａ）の前に、 前記データストリームの一部を記憶するための、少なくとも１つのデータ記憶 構造を設ける工程と、 前記少なくとも１つのデータ記憶構造内に前記データストリームの一部を記憶 する工程とが先行する、請求項４６記載の、コンピュータで読み取り可能な記憶 媒体。 ４９．ホスト処理システムのメモリ内に前記少なくとも１つのデータ記憶構造 が位置する、請求項４８記載の、コンピュータで読み取り可能な記憶媒体。 ５０．旧データストリームと新データストリームとを含む、デジタル式に符号 化されたデータストリームをスプライスするための方法であって、 （ａ）内部に決定すべきスプライスアウトポイントを有する旧データストリー ムの一部を示す、ユーザーが選択可能なパラメータを受信する工程と、 （ｂ）旧データストリーム部分および新データストリーム部分を記憶するため のスプライスバッファを割り当てる工程と、 （ｃ）旧データストリーム部分を前記スプライスバッファに向ける工程と、 （ｄ）前記スプライスアウトポイントを決定する工程と、 （ｅ）新データストリーム部分を前記スプライスバッファに向ける工程と、 （ｆ）新データストリーム部分内のスプライスインポイントを決定し、新デー タストリーム部分の初期フレームが新データストリーム部分に先行するフレーム に依存する場合、前記従属性を除くよう、新データストリーム部分を変更する工 程と、 （ｇ）前記バッファが旧データストリームの一部を最終的に受信した後に、復 号器のバッファが新データストリームの受信を、送信時に開始する場合、新デー タストリームと前記最終の受信とを整合する工程と、 （ｈ）前記バッファが旧データストリームの一部を最終的に受信する前に、復 号器のバッファが新データストリームの受信を、送信時に開始する場合、新デー タストリームと前記最終の受信とを整合する工程とを備えた、デジタル式に符号 化されたデータストリームをスプライスするための方法。 ５１．工程（ｆ）の前記従属性がオープンＧＯＰであり、前記変更が画像のオ ープングループ（ＧＯＰ）を閉じる、請求項５０記載の方法。 ５２．（ｊ）前記復号器のバッファのオーバーフローをチェックする工程と、 （ｋ）オーバーフローが見つかった場合、前記オーバーフローを除く工程とを更 に備えた、請求項５０記載の方法。 ５３．旧データストリームと新データストリームとを含む、デジタル式に符号 化されたデータストリームをスプライスするためのスプライサーであって、 （ａ）旧データストリームのスプライスアウトポイントおよび新データストリ ームのスプライスインポイントに従って新データストリームのリアルタイムの送 信開始時間を決定するための手段と、 （ｂ）前記新データストリームのリアルタイムの送信時間に従って新データス トリームと旧データストリームとを整合するための手段とを備えた、デジタル式 に符号化されたデータストリームをスプラィスするためのスプライサー。 ５４．（ａ）新データストリームのスプライスインポイントを決定する工程と 、 （ｂ）新データストリームが初期オープンＧＯＰを含む場合、新データ ストリームの初期の画像オープングループ（ＧＯＰ）を閉じる工程とを含む、デ ジタル式に符号化されたデータストリームを作成するための方法。 ５５．旧データストリームと新データストリームとを含む、デジタル式に符号 化されたデータストリームをスプライスするためのスプライサーであって、 （ａ）新データストリームのスプライスインポイントを決定する手段と、 （ｂ）新データストリームがオープンＧＯＰを含む場合、新データストリーム の画像オープングループ（ＧＯＰ）を閉じる手段とを備えた、デジタル式に符号 化されたデータストリームをスプライスするためのスプライサー。 ５６．インサートモードオプションとスプライスオンリーモードオプションと のいずれかのユーザーの選択に従って、工程（ａ）で前記スプライスアウトポイ ントを決定する、請求項５０記載の方法。 ５７．シーケンスヘッダーの直前でスプライスアウトポイントを決定する、請 求項５６記載の方法。 ５８．画像グループ（ＧＯＰ）ヘッダー、ＩフレームおよびＰフレームのうち に最初に発生する１つの直前で、スプライスアウトポイントを決定する、請求項 ５６記載の方法。 ５９．前記スプライスインポイントを決定する工程が、 新データストリームの画像グループ（ＧＯＰ）内に含まれる、新データストリ ームのフレームに対する符号化時間スタンプ（ＤＴＳ）を探す工程と、 前記フレームのための対応する提示時間スタンプを探し、前記フレームがＩフ レーム以外のフレームである場合、前記ＧＯＰを閉じる工程とを備えた、請求項 ５０記載の方法。 ６０．前記フレームが新データストリームの初期フレームである、請求項５９ 記載の方法。 ６１．前記ＤＴＳを探す工程が、第１シーケンスヘッダーに対する新データス トリームの第１部分を分析し、次に更に第１フレームヘッダー前の最終ＤＴＳに 対し、前記第１部分を分析することを含む、請求項５９記載の方法。 ６２．符号化されたデータストリーム部分の初期フレームを独立して復号化で きるように保証するための方法であって、 （ａ）前記部分内の独立して復号化できるフレームを決定する工程と、 （ｂ）前記独立して復号化可能なフレームと共に、前記部分の再生を開始させ る工程と、 （ｃ）受信復号器が前記部分の第１フレームとして前記独立して復号化可能な フレームを復号するように、前記部分の順序パラメータを変更する工程とを備え た方法。 ６３．前記独立して復号化可能なフレームに先行する前記部分内のフレームを 削除することにより工程（ｂ）を実行する、請求項６２記載の方法。 ６４．複数のフレームを含む、デジタル式に符号化されたデータストリームの オープンＧＯＰを閉じるための方法であって、 （ａ）前記ＧＯＰ内の第１Ｉフレームを決定する工程と、 （ｂ）前記ＧＯＰ内において、前記Ｉフレームに先行する前記フレームのすべ てのうちの最大のＤＴＳを決定する工程と、 （ｃ）前記Ｉフレームに先行する前記ＧＯＰ内のすべてのフレームを削除する 工程と、 （ｄ）前記ＧＯＰ内の少なくとも１つの残りのフレームに対する時間基準を変 更する工程と、 （ｅ）前記ＩフレームのＤＴＳを工程（ｂ）の前記最大のＤＴＳに置換する工 程とを備えた、オープンＧＯＰを閉じるための方法。 ６５．前記変更する工程（ｄ）が、前記ＧＯＰ内の残りのフレームの増加する 時間基準値を、工程（ｃ）で削除されたフレームの対応して増加する時間基準値 に置換することを含む、請求項６２記載の方法。 ６６．新データストリームのリアルタイム送信時間を探す工程を含む、デジタ ル式に符号化された旧データストリームのスプライスアウト部分とデジタル式に 符号化された新データストリームのスプライスイン部分とを整合するための方法 。 ６７．前記探す工程が、 （ａ）前記新データストリームの第１パケットのプログラムクロック基準（Ｐ ＣＲ）を決定する工程と、 （ｂ）前記新データストリームを送信する場合に、前記新データストリームの 第１シーケンスヘッダーの送信と、前記新データストリームの第１フレームの第 １復号化時間スタンプ（ＤＴＳ）との間のデルタ期間を決定する工程と、 （ｃ）前記第１ＤＴＳとフレーム間遅延時間との和として、連続ＤＴＳを決定 する工程と、 （ｄ）前記連続ＤＴＳと前記デルタ期間との差として、前記新データストリー ムのリアルタイム送信時間を決定する工程とを備えた、請求項６６記載の方法。 ６８．前記探す工程を前記新データストリームと前記旧データストリームとの スプライス中にリアルタイムで実行する、請求項６６記載の方法。 ６９．前記フレーム間遅延時間が１００１／３０，０００秒である、請求項６ ７記載の方法。 ７０．デジタル式に符号化された旧データストリームのスプライスアウト部分 とデジタル式に符号化された新データストリームのスプライスイン部分とを整合 するための方法であって、前記新データストリームの受信時間の開始を設定する ことを含み、この受信時間において前記新データストリームを送信する場合、前 記旧データストリームの前記スプライスアウト部分に対する復号化時間と整合し て、復号器による前記新データストリームの受信を開始する方法。 ７１．前記データストリームの送信時に復号器が前記スプライスアウト部分の すべてを受信する前に、復号器により前記新データストリームの受信を開始する 場合、前記設定する工程が前記新データストリームのための送信遅延パラメータ を設定することを含む、請求項７０記載の方法。 ７２．前記新データストリームを送信する場合、他の新データストリームのデ ータのほぼ前でゼロパケットを送信するよう、前記新データストリームの位置に 前記遅延パラメータに対応する数のゼロパケットを挿入することを更に含む、請 求項７１記載の方法。 ７３．新データストリームを送信する場合、復号器が前記スプライスアウト部 分のすべてを受信する前に、挿入することなく受信されるデータパケットの数に 前記ゼロパケットの数が等しい、請求項７２記載の方法。 ７４．送信時において、復号器が前記スプライスアウト部分のすべてを受信し た後に、前記新データストリームが復号器によって受信され始める場合、前記新 データストリームに対する送信加速パラメータを設定することを、前記設定工程 が含む、請求項７０記載の方法。 ７５．前記新データストリームを送信する場合、前記新データストリームの最 初に送信された部分から前記加速パラメータを対応して有する数のゼロパケット を削除することを更に含む、請求項７４記載の方法。 ７６．新データストリームを送信する場合、復号器が前記スプライスアウト部 分のすべてを受信した後に、前記削除を行うことなく復号器によって受信される データパケットの数に前記ゼロパケットの数が等しい、請求項７５記載の方法。 ７７．デジタル式に符号化された旧データストリームのスプライスアウト部分 とデジタル式に符号化された新データストリームのスプライスイン部分の各々が 複数のパケットを含み、前記スプライスアウト部分と前記スプライスイン部分と を整合するための方法であって、 （ａ）送信すべき前記スプライスアウト部分の最終パケットのプログラムクロ ック基準（ＰＣＲ）のために前記スプライスアウト部分を分析する工程と、 （ｂ）前記新データストリームの第１フレームの第１シーケンスヘッダーおよ び第１復号化時間スタンプ（ＤＴＳ）に対する前記スプライスイン部分を分析す る工程と、 （ｃ）前記新データストリームの連続ＤＴＳを決定する工程と、 （ｄ）工程（ａ）のスプライスアウトＰＣＲが工程（ｃ）のリアルタイムの送 信時間よりも短い場合に、前記スプライスイン部分よりも前で送信する際に、前 記スプライスアウト部分の復号化とほぼ同じ時間に前記スプライスイン部分の送 信を開始させるゼロパケットの総数を示す値を記憶する工程と、 （ｅ）工程（ａ）の前記スプライスアウト部分ＰＣＲが工程（ｃ）の前記リア ルタイムの送信時間よりも長い場合に、前記スプライスイン部分から削除する際 に、スプライスアウト部分ＰＣＲがリアルタイムの送信時間に等しくなる状態に 近似させるゼロパケットの総数を記憶する工程とを備えた方法。 ７８．データストリーム部分のスケジュールされた送信時間を加速および遅延 させる値を決定するためのシフト手段と、前記シフト手段によって決定された値 だけ加速または遅延された送信時間で前記データストリーム部分を送信するため の送信手段とを備えた、デジタル式に符号化されたデータストリーム送信機。 ７９．前記新データストリームのデータを複数のデータパケットとして受信す る、請求項７８記載の装置。 ８０．前記遅延値をデータストリームのデータのデータパケットの数に対応す る時間として計算する、請求項７９記載の装置。 ８１．デジタル式に符号化された新データストリームを、デジタル式に符号化 された旧データストリームにスプライスされた状態で送信するための送信機であ って、 送信機と、 前記旧データストリームへの前記新データストリームのスプライシングに対応 する時間に、前記新データストリームのうちの新データストリームのデータの送 信をスケジュールするためのビットクロック手段とを備えた送信機。